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1.1     PURPOSE  OF  THIS  DOCUMENT 

This  document  records  current  stable  implementation  agreements  of  OSI 
protocols  among  the  organizations  participating  in  the  NIST  Workshop 
for  Implementors  of  OSI.     Stable  in  the  context  of  this  document 
means  that : 

1)  The  agreements  are  based  on  final  standards 
(e.g.,  ISO-IS  or  CCITT  Recommendations)  or 
nearly  final  (e.g.,  ISO-DIS)  with  no 
significant  changes  expected,  and, 

2)  The  agreements  have  been  approved  by  the  NIST 
Workshop  Plenary  for  progression  from  the 
Working  Agreements  document  to  this  document 
after  a  period  of  review.     These  agreements  are 
considered  final;  the  only  changes  allowed  will 
be  clarifications,  and  certain  Technical  and 
Alignment  errata.     These  changes  must  have  the 
strong  support  of  vendors,  and  be  justifiable. 

For  these  reasons,  the  agreements  are  considered  advanced  enough  for 
use  in  product  and  test  suite  development.     This  means  that  readers 
can  use  this  text  as  a  basis  for  procurement  references  for  OSI 
products.     All  of  the  text  in  this  document  is  considered  stable  as 
defined  above . 

Future  releases  of  these  Stable  Agreements  will  add  and/or  extend 
functionality  offered  by  this  edition  and  version.     When  required,  new 
versions  will  be  introduced  on  a  yearly  basis.     It  is  the  NIST 
Workshop  intent  that  new  versions  of  this  Stable  Agreements  document 
will  be  compatible  with  the  present  version.     If  this  proves 
impractical,  the  agreements  will  attempt  to  provide  mechanisms  and 
guidelines  which  maximize  interoperability.     Furthermore,  it  is  the 
intent  that  these  stable  agreements  be  maintained  via  the  Errata 
process  as  long  as  is  appropriate.     For  the  subject  area,  interworking 
information  and  other  useful  advice  to  the  reader  is  given  as 
appropriate.     Specific  "defect  report"  information  (including  extent 
of  applicability)  is  provided  in  the  ERRATA  portions  of  each  Chapter. 

Agreements  text  is  either  in  this  Stable  Document  (Stable)  or  in  the 
aligned  Working  Document  (not  yet  stable) .     It  is  a  goal  that  the  same 
text  not  appear  in  the  same  position  in  both  documents  at  once  (except 
for  sec.   1).     New  editions  of  a  version  reflect  very  recent  stable 
functionality  as  well  as  editorial,  technical,  and  alignment  errata, 
all  applied  to  the  previous  edition. 
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The  intended  audience  for  this  document  is  composed  of  those 
individuals  who  are  interested  in  Stable  Implementation  Agreements  for 
OSI  protocols.     Each  section  of  the  document  covers  a  different 
subject  area,  and  the  sections  are  presented  so  as  to  present  a 
consistent  and  unified  approach.     The  structure  of  each  section, 
whenever  possible,   is  divided  into  the  following  subsections: 

o  Introduction, 

o        Scope  and  Field  of  Application, 
o  Status, 
o  Errata, 

o        Protocol  and  Service  Agreements, 
o        Conformance ,  and 
o  Appendices. 

The  corresponding  and  aligned  document,   "Working  Implementation 
Agreements  for  OSI  Protocols  dated  September  1990,"  records  agreements 
which  are  not  yet  considered  stable,   in  the  sense  described  above. 
This  document  will  be  referenced  as  the  "Working  Agreements 
Document."     This  Stable  document  is  aligned  with  the  Working 
Agreements  Document  in  the  sense  that  the  structures  are  identical, 
and  pointers  are  given  in  this  Stable  Document  to  work  in  the  Working 
Agreements  Document  which  could  become  stable  in  the  future. 

The  benefit  of  this  document  to  the  reader  is  that  it  gives  a  complete 
accounting  of  current  stable  agreements.     Minor  changes  (Errata)  to 
these  agreements  will  be  issued  in  replacement  page  format  as  separate 
editions.     These  errata  will  only  be  applied  to  the  current  version. 

Version  3  (this  version)  is  backwards  compatible  with  Version  2  to  the 
maximum  extent  possible.     Version  3  includes  all  of  the  material  from 
Version  2,   (modified  by  errata)  as  well  as  now  stable  material  from 
the  previous  year;   important  new  functional  additions  from  Version  2 
are  in  the  areas  of  certain  aspects  of  Lower  Layers  network 
technology,  X.3  Virtual  Terminal  profile,  Workshop  Registration 
procedures,  new  Upper  Layer  and  Directory  Services  agreements,  and  new 
FTAM  and  1988-Based  X.400  agreements. 

1.2     PURPOSE  OF  THE  WORKSHOP 

In  February,   1983,  at  the  request  of  industry,  NIST  organized  the  NIST 
Workshop  for  Implementors  of  OSI  to  bring  together  future  users  and 
potential  suppliers  of  OSI  protocols.     The  Workshop  accepts  as  input 
the  specifications  of  emerging  standards  for  protocols  and  produces  as 
output  agreements  on  the  implementation  and  testing  particulars  of 
these  protocols.     This  process  is  expected  to  expedite  the  development 
of  OSI  protocols  and  promote  interoperability  of  independently 
manufactured  data  communications  equipment. 
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1.3  WORKSHOP  ORGANIZATION 

The  Workshop  organizes  its  work  through  Special  Interest  Groups 
(SIGs)  that  prepare  technical  documentation.     An  executive  committee 
of  SIG  chairpersons  led  by  the  overall  Workshop  chairperson 
administers  the  Workshop.     NIST  invites  highly  qualified  technical 
leaders  from  participating  organizations  to  assume  leadership  roles  in 
the  SIGs.     The  SIGs  are  encouraged  to  coordinate  with  standards 
organizations  and  user  groups,  and  to  seek  widespread  technical 
consensus  on  implementation  agreements  through  international 
discussions  and  liaison  activities. 

The  Workshop  meets  four  times  a  year  at  the  National  Institute  of 
Standards  and  Technology  in  Gaithersburg ,  Maryland  where  each  SIG  is 
required  to  convene  its  meeting.     In  addition,  a  plenary  assembly  of 
all  Workshop  delegates  is  convened  for  consideration  of  SIG  motions 
and  other  Workshop  business.     SIGs  are  also  encouraged  to  hold  interim 
meetings  at  varied  locations  around  the  world. 

The  Workshop  is  an  open  public  forum.     Registration  materials, 
documents,  and  Workshop  schedules  are  available  from: 

National  Institute  of  Standards  and  Technology 
NIST  Workshop  for  Implementors  of  OSI 
Building  225,  Room  B-217 
Gaithersburg,  Maryland  20899 

1.4  USE  AND  ENDORSEMENT  BY  OTHER  ENTERPRISES 

The  Workshops  are  held  for  those  organizations  expressing  an  interest 
in  implementing  or  procuring  OSI  Protocols  and  Open  Systems.  However, 
there  is  no  corporate  commitment  to  implementations  associated  with 
Workshop  participation. 

The  Workshop  and  associated  agreements  have  been  endorsed  by  various 
activities  and  groups.     See  the  aligned  section  of  the  Working 
Agreements  Document  for  more  on  this  subject. 

1.5  RELATIONSHIP  OF  THE  WORKSHOP  TO  THE  NIST 

As  resources  permit,  NIST,  with  voluntary  assistance  from  industry, 
develops  formal  protocol  specifications,  reference  implementations, 
tests,  and  test  systems  for  the  protocols  agreed  to  in  the  Workshops. 
The  NIST  organizes,  administers,  and  makes  technical  contributions  to 
the  Workshop.     The  NIST  bears  no  other  relation  to  the  workshop. 
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1.6  STRUCTURE  AND  OPERATION  OF  WORKSHOP 
1.6.1  Plenary 

The  main  body  of  the  workshop  is  a  Plenary  Assembly.  Any 
organization  may  participate.     Representation  is  international. 
The  NIST  prefers  for  the  business  of  Workshops  to  be  conducted 
informally  since  there  are  no  corresponding  formal  commitments 
within  the  Workshop  to  implement  the  decisions  reached.     For  more 
information,  consult  the  aligned  section  of  the  Working 
Agreements  Document. 

1.6.2  Special  Interest  Groups 

Within  the  Workshop  there  are  Special  Interest  Groups  (SIGs) . 
The  SIGs  receive  their  instructions  for  their  technical  program 
of  work  from  the  Plenary.     The  SIGs  meet  independently  during 
the  Workshop  week.     As  technical  work  is  completed  by  a  SIG,  it 
is  presented  to  the  Plenary  for  disposition.     For  more 
information  on  SIGs  (including  SIG  charters),  consult  the  aligned 
section  of  the  Working  Agreements  Document. 

1.7  POINTS  OF  CONTACT 

For  information  concerning  the  workshop,  write  to: 

Chair,  NIST  Workshop  for  Implementors  of  OSI 
at  the  address  given  in  section  1.3. 

Individual  points  of  contact  are  given  in  the  aligned  section  of  the 
Working  Agreements  Document. 

1.8  PROFILE  CONFORMANCE 

This  section  presents  general  concepts  for  profile  conformance.  These 
concepts  shall  be  obseirved  when  writing  Implementation  Agreements. 

1.8.1  General  Principle 

Conformance  to  an  OSI  Profile  (Implementation  Agreements, 
Functional  Standards)  implies  conformance  to  the  referenced  Base 
Standards . 
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Therefore,  a  Profile  shall  not  specify  any  requirements  that 
would  contradict  or  cause  non- conformance  to  the  Base  Standards 
to  which  it  refers  (see  TR  10000-1,  clauses  6.1,  6.3.1).  The 
conformance  requirements  defined  in  ISO/IEC  TR  10000-1  fully 
apply. 

1.8.2  Constraints 

Base  standards  usually  provide  options  for  PDUs ,  parameters, 
encoding  choices,  value  ranges,  etc. 

A  profile  may  make  specific  choices  of  these  options  and  ranges 
of  values.     For  the  promotion  of  interoperability,  pragmatic 
constraints  or  minimum  requirements  may  be  imposed  (e.g.,  the 
limitation  of  Search  operations,  selection  of  encoding  choices, 
value  ranges ,  byte  ranges  for  encoding) .     These  minimum 
requirements  of  restrictions  shall  not  contradict  the 
conformance  requirements  of  the  respective  base  standards. 

1 ■ 8 ■ 2 ■ 1      Sending/Encoding  Entity 

In  order  to  promote  interworking ,  reasonable  restrictions  or 
minimum  requirements  may  be  specified  in  a  profile  as 
described  above . 

1.8.2.2      Receiving/Decoding  Entity 

Minimum  requirements  of  receiving/decoding  capability  for 
alternatives,  permissible  values,  etc.  may  be  specified  in  a 
profile.     A  profile  shall  not  specify  the  behavior  of  a 
receiving/decoding  entity  when  receiving  data  which  is 
outside  the  scope  of  or  excluded  by  the  Profile  for  senders. 

A  Profile  Conformance  Test  shall  be  limited  by  the  scope  of 
the  profile  specification  and  shall  not  probe  beyond  its 
boundaries.     That  means,  the  capability  of  a 
receiver/decoder  would  be  tested  only  in  the  range  of 
choices  or  values  which  are  specified  for  the 
sending/encoding  entity  (i.e.,   for  interworking  between 
systems  both  being  conformant  to  the  Profiles) . 
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1.8.3  Classification  of  Conformance 


Conformance  requirements  of  a  profile  shall  be  related  to 
conformance  requirements  of  a  base  standard  as  written  in  clause 
6.5  and  annnex  C  of  ISO/IEC  TR  10000-1.     For  the  conformance 
classes,  the  following  terminology  shall  be  used  unless 
otherwise  specified  by  the  base  standard  or  equivalent 
conformance  requirements  for  a  profile  as  required  by  the  ISO/IEC 
Technical  Committee  that  is  responsible  for  the  base  standard: 

m  mandatory 

0  optional 

c  conditional 
X  excluded 

1  out  of  scope 
not  applicable 
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2^  SUB  NETWORKS 

Editor's  Note:  The  term  "Ongoing"  used  in  this  document  refers  to  the 
I  Working  Implementation  Agreements  dated  September  1990. 

2.1  INTRODUCTION 

This  chapter  provides  agreements  about  subnetwork  services  used  in 
support  of  the  OSI  Network  Layer. 

2.2  SCOPE  AND  FIELD  OF  APPLICATION 

These  agreements  cover  subnetwork  types  including  local  area  networks, 
packet  switched  networks,  circuit  switched  networks,  ISDN,  and  others. 


2.3  STATUS 

This  version  was  completed  in  March  1990.     Updated  material  has  been 
moved  into  section  2.5.2  from  the  Working  Implementation  Agreements 
Document  to  replace  existing  text. 

2.4  ERRATA 


2.5    LOCAL  AREA  NETWORKS 


2.5.1  IEEE  802.2  LOGICAL  LINK  CONTROL 

The  following  decisions  have  bean  reached  with  respect  to  this 
protocol . 

1.      Link  Service  Access  Point  (LSAP) 

The  code  below  shall  be  used  to  address  systems  using 
Network  Layer  protocols  identified  by  ISO  TR  9577  (e.g.,  ISO 
8473,  ISO  8208).    Note  that  bit  zero  is  transmitted  first. 

The  most  significant  bit  is  bit  7,  thus  this  bit  pattern 
represents  hexadecimal  FE. 


0 

1 

2 

3 

4  5 

6 

7 

0 

1 

1 

1 

1  j  1 

1 

1 
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Figure  2.1.     LSAP  bit  pattern. 
Type  and  Class 

Only  the  connectionless  type  1,  class  1  IEEE  802  link 
service  will  be  used. 


2.5.2  IEEE  802.3  CSMA/CD  ACCESS  METHOD 


The  following  implementation  agreements  have  been  reached  with 
respect  to  the  IEEE  802.3  CSMA/CD  Access  Method  and  Physical 
Layer  Specifications: 

o        The  address  length  shall  be  48  bits 

o        For  a  data  packet  of  LLC  data  length  of  n  octets,  the 
length  of  the  pad  field  is 

max(0,  minFrameSize- (8n+2 (addressSize)+48) )  bits. 

The  following  implementation  agreements  have  been  reached  with 
respect  to  10  BROAD  36  Networks: 

1.       Single  Cable  Networks 

The  translator  frequency  shall  be  192.25  Mhz 

The  channel  allocations  are 

Reverse  Channels  Forward  Channels 


T12,  T13,  T14 
T13,  T14,  2' 
T14,  2' ,  3' 
2' ,   3' ,  4' 
3'  ,  4' ,  4A' 
4' ,  4A' ,  5' 


L,  M,  N 

M,  N,  0 

N,  0,  P 

0,  P,  Q 

P,  Q,  R 

Q.  R,  S 


2-2 


December   ' 89 


2.  Dual  Cable  Networks 

For  nontranslated  dual  cable  networks  forward  and 
reverse  frequencies  are  the  same.  Permissible 
channel  allocations  are: 

T12,  T13,  T14 
T13,  T14,  2' 
T14,   2' ,  3' 
2' ,   3' ,  4' 
3' ,  4' ,  4A' 
4' ,  4A' ,  5' 
L,  M,  N 
M,   N,  0 
N,   0,  P 
0,   P,  Q 
Q,   R,  S 

3.  When  both  IEEE  802.4  and  IEEE  802.3  10  BROAD  36 
networks  coexist  on  the  broadband  cable  system  the 
preferred  channel  allocations  are: 

Reverse  Forward 

IEEE  802.3  T12,   T13,   T14  L,  M,  N 

IEEE  802.4  6' ,   FMl'  T,  U 

channels  3' ,   4'  P,  Q 

reserved  for  4A' ,   5'  R,  S 

future  use 


2.5.3  IEEE  802.4  TOKEN  BUS  ACCESS  METHOD 

The  following  options  are  agreed  to  with  respect  to  Draft  J  of 
token  bus : 


o        Data  Rate: 

10  Mb  (Broadband) 
5  Mb  (Carrierband) 

o        Addressing:  48  bit 

o        The  ImeOption,   Priority  Mechanism,   shall  be  implemented 
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Broadband  Channel  Assignments 


Forward  Reverse 

P  3' 

Q  4' 

R  4A' 

S  5' 

T  6' 

U  FMl 


2.5.4  IEEE  802.5  TOKEN  RING  ACCESS  METHOD 

The  following  implementation  agreements  have  been  reached  with 
respect  to  the  IEEE  Standard  802.5,  Token  Passing  Ring  Access 
Method  and  Physical  Layer  specification. 

o        The  data  signalling  rate  shall  be  4  Mbit/s 

o        The  address  length  shall  be  48  bits 

o        The  message  priority  (PM)  of  the  AMP  data  unit  shall  be 
7 

o        The  ALL_STATIONS_THIS_RING_ADDRESS  shall  be 
X'COOOFFFFFFFF' 

o  The  TRR  value  shall  be  4  milliseconds 

o  The  THT  value  shall  be  8 . 9  milliseconds 

o  The  TQP  value  shall  be  20  milliseconds 

o  The  TVX  value  shall  be  10 _ milliseconds 

.o  The  TNT  value  shall  be  2 . 6  milliseconds 

o  The  TAM  value  shall  be  7  seconds 

o  The  TSM  value  shall  be  15  seconds 
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o        The  MAC  Information  field  (I-field)  shall  be  defined  as 
follows : 


Starting  Sequence 


I-Field 


End  Sequence 


and  the : 

1)  Starting  Sequence  includes:   SD,  AC,   FC ,   DA,  SA 

2)  Ending  Sequence  includes:  FCS ,   ED,  FS 


Figure  2.2.     I-Field  Format. 


With  the  above  timer  and  MAC  I-field  definitions,  the 
following  limits  are  defined: 

Protocol  limits  the  I-field  to  a  maximum  of  4425 
bytes ,  and 

All  stations  shall  support  I-fields  that  have  a 
minimum  of  one  byte  and  a  maximum  of  at  least  2000 
bytes . 


2.5.5  FIBER  DISTRIBUTED  DATA  INTERFACE  (FDDI) 


2.5.5.1      Token  Ring  Media  Access  Control  (MAC.  X3. 139-1987) 

(Refer  to  the  Ongoing  Implementation  Agreements 
Document) 


2.5.5.2       TOKEN  RING  PHYSICAL  LEVEL  ( PHY , X3 . 148 -  1988 ) 

(Refer  to  the  Ongoing  Implementation  Agreements 
Document) 


2.5.5.3      PHYSICAL  LAYER  MEDIA  DEPENDENT  (PMD.  X3. 166- 1989) 

(Refer  to  the  Ongoing  Implementation  Agreements 
Document) 


2.6    WIDE  AREA  NETWORKS 
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2.6.1  CCITT  RECOMMENDATION  X.25 

The  procedures  required  to  describe  the  DTE  side  of  a  DTE/DCE 
interface  for  systems  attached  to  sub-networks  providing  an  X.25 
interface  shall  be  as  defined  in  ISO  7776  and  ISO    8208  and  as 
supplemented  below.     (These  procedures  shall  also  apply  to  a  DTE 
operating  on  a  DTE/DTE  interface). 


2.6.2  ISO  7776 

ISO  7776  is  used  as  the  Layer  2  Protocol  with  the  agreements 
defined  below. 

1  The  address  assignments  are: 

DTE  =  A  (=11000000  binary) 
DCE  =  B  (=10000000  binary) 

On  a  DTE/DTE  interface,  one  of  the  DTEs ,  by  a  prior 
agreement,   shall  use  the  DCE  address. 

2  The  modulus  shall  be  8. 

3  A  window  size  (k)  of  7  shall  be  supported.  In 
addition,   other  window  sizes  may  also  be  supported. 

4  The  Multilink  Procedures  are  excluded. 


2.6.3  ISO  8208  ^  . 

The  elements  of  ISO  8208  applicable  for  use  depend  on  the  OSI 
role  of  ISO  8208  (ie,,     provision  of  CONS,   support  of  CLNP) . 
Independent  of  the  role,   ISO  8208  is  used  as  the  Layer  3 
protocol,  with  the  following  agreements: 

1  Virtual  Call  Service, 

2  any  mutually  agreed  window  and  packet  size,  however, 
all  DTEs  must  be  capable  of  supporting  a  window  size  of 
2,   a  packet  size  of  128  octets,   and  a  sequence  number 
modulus  of  8 , 

■  S-*  ■     a  DTE  must  be    capable  of  receiving  the  Flow  Control 
Parameter  Negotiation  Facility  and  responding 
appropriately  (per  ISO  8208) ,  and 
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4        The  Basic  RPOA  Selection  Facility  shall  be  implemented 
and  its  use  or  non-use  selectable  on  a  per  virtual  call 
basis . 

VThen  ISO  8208  is  used  to  support  CONS,   the  optional  user 
facilities  in     Clause  5.1  of  ISO     8878  shall  also  be  supported. 

\^^hen  ISO  8208  is  used  to  support  CLNP  (when  providing  the  CLNS), 
Permanent  Virtual  Circuit  Service  may  also  be  used. 

2.7     INTEGRATED  SERVICES  DIGITAL  NETWORKS  (ISDN) 

2.7.1  Introduction 

This  section  defines  Implementation  Agreements  for  packet-data 
transfer  in  an  ISDN  context.     The  agreements  provide  a  set  of 
procedures  for  accessing  an  ISDN  so  that  end  systems  implemented 
according  to  these  agreements  can  obtain  ISDN  services  and  can 
successfully  interoperate . 

The  agreements  are  not  meant  to  preclude  vendors  from 
implementing  additional  procedures  as  long  as  they  do  not  create 
system  interoperability  problems.     Capabilities  will  vary  from 
ISDN  to  ISDN  and  procedures  beyond  those  included  here  may  be 
necessary  to  request  and  utilize  network  services  more 
effectively  and  fully. 

The  agreements  cover  two  fundamental  ISDN  services  for  X.25 
packet  mode  ISDN  terminals,  namely, 

CASE  I:       The  ISDN  provides  a  circuit-mode   (Layer  1) 
connection  either  on  demand  ("switched")  or 
permanently  ("dedicated  circuit").  A  general 
description  of  the  corresponding  ISDN  64  Kbps 
circuit-mode  bearer  service  is  described  in  CCITT 
Recommendation  1.231.     The  circuit-mode 
connection  is  between  an  X.25  ISDN  terminal  and 
(i)   a  PSPDN,   or  (ii)  another  X.25  ISDN  terminal. 
The  circuit-mode  connection  to  a  PSPDN 
corresponds  to  CASE  A  of  CCITT  Recommendation 
X.31. 

CASE  II:     The  ISDN  provides  the  X.25  virtual  circuit 

service.     A  general  description  of  this  service  is 
given  in  CCITT  Recommendation  1.232.     This  case 
corresponds  to  CASE  B  of  CCITT  Recommendation 
X.31. 
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Figures  2.3  and  2.4  give  the  agreed  stacks  for  X.25  packet 
transfer  over    D  and  B  channels,  respectively.     Some  particular 
aspects  are  given  below. 

1.  The  packet  data  transfer  is  on  a  B  channel  of  a  Basic 
Access  or  a  Primary  Rate  Interface.     In  CASE  II,   it  can 
be  on  a  D  channel  of  a  Basic  Access  Interface. 

2.  The  layer  2  procedures  are  LAPB  (ISO  7776)  on  a  B 
channel  and  LAPD  (CCITT  Recommendation  Q.921)  on  a  D 
channe 1 . 

3.  X.25  PLP  (ISO  8208)  procedures  are  used,   including  the 
setting  up  and  clearing  of  virtual  calls. 

4.  Q.921  and  Q.931  procedures  on  a  D  channel  are  used  for 
access  signaling,  when  appropriate,   to  select  the  B  or 
D  channel  for  packet  data  transfer  and  for  establishing 
and  releasing  a  physical  path  in  the  ISDN. 

5.  Refer  to  chapter  3  for  the  specification  of  methods  for 
providing  OSI  Network  Services. 

2.7.2  Implementation  Agreements 

This  section  gives  Implementation  Agreements  for  individual  ISDN- 
related  protocols.     The  relevant  protocol  stacks  are  given  in 
figures  2.3  and  2.4. 
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OS I  LAYER 
3 


Q.931 
(1.451) 


ISO  8208 
(X.25  PLP) 


Q.921  (1.441) 
(LAPD) 


 1  

D  CHANNEL 

ANS  Tl. 601-1988,     ANS  Tl. 605-1989 


ADDITIONAL  SIGNALING 
FOR  INCOMING  PACKET  * 
CALLS 


PACKET  SWITCHED 
SIGNALING  AND  INFORMATION 
TRANSFER 


*  MAY  BE  NULL 


Figure  2.3.         Protocol  Layers  at    S,  T  and  U  reference  points 
when  D  Channel  is  used  in  ISDN. 
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OS I  LAYER 


Q.931 
(1.451) 


ISO  8208 
(X.25  PLP) 


Q.921 
(LAPD) 


ISO  7776 
(X.25  LAPB) 


D  CHANNEL 


B  CHANNEL 


ANS  Tl. 601-1988,  ANS  Tl. 605-1989 
and  for  Primary  Rate  ANS  Tl. 403- 1989 


I  1  1    I  1 

SIGNALING  FOR  CIRCUIT 
SWITCHED  ACCESS* 
ADDITIONAL  SIGNALING 
FOR  INCOMING  PACKET 
CALLS* 

*  MAY  BE  NULL 

igure  2.4.         Protocol  Layers  at     S,   T  and  U  reference  points 
■.■  when  B  Channel  is  used  in  ISDN. 


2  ■  7  ■  2  ■  1       Physical  Layer.   Basic  Access  at  "U" 

ANS  Tl. 601-1988,   "Integrated  Services  Digital  Network-Basic 
Access  Interface  for  Use  on  Metallic  Loops  for  Application 
on  the  Network  Side  of  the  NT-Layer  1  Specification" 
applies . 


PACKET  SWITCHED 
SIGNALING  AND  INFORMATION 
TRANSFER 


2.7.2.2       Physical  Layer.   Basic  Access  at  S  and  T 

ANS  Tl. 605-1989,    "Integrated  Services  Digital  Network- Bas ic 
Access  Interface  at  S  and  T  Reference  Points-Layer  1 
Specifications"  applies. 


2.7.2.3       Physical  Layer.   Primary  Rate  at  "U" 
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The  physical  layer  is  governed^  by    ANS  Tl. 403- 1989, 
"Carrier-to-Customer  Installation  Metallic  Interface,"  and 
CCITT  Recommendation  1.431-1988,   "Primary  Rate  User-Network 
Interface  -  Layer  1  Specification  subject  to  the  exceptions 
given  below. 

The  following  portions  of  ANS    Tl. 403. 1989  shall  be 
deleted. 


-  Section  5.3.1 

-  Section  5.6: 

-  Section  6.1: 

-  Section  6.3: 

-  Section  8.0: 

-  Section  8.3: 

-  Section  8.4.1: 

-  Section  9/ 
figure  9 

-  Table  2 

-  Table  3 


The  bit  rate  tolerance  option  of 
+/-  200  bps. 

The  minimum  pulse  density  of  this 
section. 

The  superframe  format. 

The  complete  section. 

The  reference  to  the  SF  format. 

The  text  in  paragraph  8.3.1.1  and 
footnote  7(8.3.1.2). 

Footnote  9 . 

Provisions  for  the  use  of  the  RJ48M 
connector . 

This  table. 

The  illustration  in  table  3  of 
"Robbed-Bit  Signaling." 


ANSI  accredited  subcommittee  TlEl  is  developing  a  standard  for 
the  ISDN  primary  rate  interface  at  reference  points  "S"  and 
"T"  as  well  as  "U".     One  of  the  accepted  guidelines  for  the 
standard  is  consistency  with    ANS  Tl. 403- 1989.     It  is  intended 
that,  when  this  new  ISDN-unique  standard  is  adopted,  this 
agreement  will  be  modified  to  reference  it  and  will  be 
extended  to  cover  interfaces  at  reference  points  "S"  and  "T" 
as  well  as  "U" .     The  current  standard  mentioned  is  at  the 
default  letter  ballot  level  of  the  draft  document:  TlEl-2/89- 
046R4,   "ISDN  Primary  Rate  Customer  Installation  Interfaces 
Layer  1  Specification." 
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The  following    portions  of    ANS  Tl. 403-1989  shall  be 
modified  : 

-  Section  5.3.2  The  text  of  this  section  is 

replaced  by: 

"The  line  code  is  B8ZS  except  as 
noted  in  section  7,"  and 

'• '       -  Section  7.0:  The  reference  to  the  pulse  density 

requirements  of  section  5.6  is 
inappropriate.     The  text  is 
'  '      ■  :  replaced  by : 

'        '  "The  provisions  of  Clear  Channel 

Capability  (CCC)   depends  upon  the 
use  of  the  B8ZS  line  code,  though 
the  use  of  ZBTSI  is  one  interim 
method  that  may  be  employed  by 
agreement  of  the  network  and  the 
user" 

The  provisions  of  ANS  Tl. 403-1989  shall  be  supplemented  by 
the  provisions  of  CCITT  Recommendation  1.431   -   section  4.4. 

2.7.2.4  Data  Link  Layer.  D-Channel 

CCITT  Recommendation  Q.921   (1.441),    "ISDN  User-Network 
Interface  Data  Link  Layer  Specification"  applies. 

2.7.2.5  Signaling 

CCITT  Recommendations  Q.931   (1.451),    "ISDN  User-Network 
Interface  Layer  3  Specification"  applies. 

The  following  agreements  have  been  reached  concerning  the 
use  of  Q.931 . 

1        On  a  Basic  Rate  Interface  supporting  the  ISDN 

virtual  circuit  service,   all  of  Q.931  section  6 
except  for  6.1.1  and  6.2.1   (the  sections  covering 
the  circuit-switched  access  case)  shall  apply. 
The  following  sections  also  apply:     2.2,  packet 
mode  access  connection  states;   3.2,  messages  for 
packet  mode  access  connection  control;  4-4.5, 
section  specifying  general  information  element 
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handling  and  encoding;  4.7,   information  elements 
for  packet  communications. 

On  a  Primary  Rate  Interface  supporting  the  ISDN 
virtual  circuit  service  all  of  Q.931  section  6 
shall  apply  except  for  6.1.1  and  6.2.1  (the 
sections  specifying  the  circuit  switched  access 
case),   6.1.2.2,   6.2.2.2  and  6.4.2   (the  sections 
specifying  D-Channel  ISDN  Virtual  Circuit  service 
case).     The  following  sections  also  apply:  2.2, 
packet  mode  access  connection  states;  3.2 
messages  for  packet  mode  access  connection 
control;   4-4.5,   sections  specifying  general 
information  element  handling  and  encoding;  4.7, 
Information  elements  for  packet  communications. 

On  a  Basic  or  Primary  Rate  Interface  supporting 
the  unrestricted  64-Kbps  circuit-mode  service, 
Q.931  sections  6.1.1,   6.2.1,     6.4.1  and  6.4.3 
shall  apply.     The  following  sections  also  apply: 
2.1,   circuit  mode  connection  states;   3.1,  messages 
for  circuit  mode  connection  control;  4-4.5, 
sections  specifying  general  information  element 
handling  and  encoding. 


2.7.2.6      Data  Link  Layer  B-Channel 

The  agreements  on  ISO  7776  specified  in  section  2.6.2  shall 
apply  here. 

If  the  ISDN  provides  a  circuit-mode  service  between  two  ISDN 
packet-mode  devices,   then  the  layer  2  address  shall  be 
assigned  as  follows: 


For  permanent  ( "non- switched" )  circuit-mode 
service,   one  terminal  uses  address  A  and  the  other 
terminal  uses  address  B,   as  arranged  by  prior 
agreement ,  and 

For  demand  ("switched")  circuit-mode  service,  the 
terminal  originating  the  circuit-mode  call  uses 
address  A  and  the  other  terminal  uses  address  B. 


2.7.2.7      Packet  Layer 
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The  agreements  on  ISO  8208  specified  in  section     2.6.3  shall 
apply  here.     When  ISO  8208  is  used  on  the  D-Channel,  the 
maximum  DATA  packet  size  (i.e.,   actually  the  maximum  size  of 
the  User  Data  Field  in  a  DATA  packet)  shall  be  limited  to 
256  octets. 


2 . 8     APPENDIX  A 


This  appendix  provides  a  cross-reference  listing  between  those 
sections  of  the  CCITT  ISDN  Recommendations  given  in  section  2.7  of 
this  document  and  the  sections  of  the  corresponding  ANSI  ISDN 
Standards.     This  appendix  does  not  supersede  section  2.7  but  merely 
provides  a  pointer  to  those  who  wish  to  implement  the  ISDN  procedures 
based  on  ANSI  Standards. 


2.8.1  Data  Link  Layer.  D-Channel 

CCITT  Recommendation  Q.921,  which  is  referenced  in  section 
2.7.2.4  of  this  document,   is  identical  to  ANSI  Standard  Tl . 602 . 


2.8.2  Signaling 

The  following  table  provides  the  cross-references  between  those 
sections  of  CCITT  Recommendation  Q.931  referenced  in  section 
2.7.2.5  of  this  document  and  the  corresponding  ANSI  ISDN 
Standards . 
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Tabie  2.1.     ANSI-CCITT  Cross -References 


CCITT  RECOMMENDATION  Q.931 

ANSI  Tl 

608 

Section 

2 

■1 

1 

Section 

4. 

1 

(refers  to  sec. 

2.1.1 

of  ANSI  Tl .607) 

Section 

2 

2 

Section 

4. 

2 

Section 

3 

1 

Section 

5. 

1 

(refers  to  sec. 

3  of  ANSI 

Tl . 607) 

Section 

3 

2 

Section 

5. 

2 

Section 

4 

1 

Section 

6. 

1 

Section 

4 

2 

Section 

6. 

2 

Section 

4 

3 

Section 

6. 

3 

Section 

4 

4 

Section 

6. 

4 

Section 

4 

5 

Section 

6. 

5 

Section 

4 

7 

Section 

6  . 

5 

Section 

6 

Section 

7 

Section 

6 

1 

1 

Section 

7  . 

1 

1 

Section 

6 

1 

2 

2 

Section 

7  . 

1 

2.2 

Section 

6 

2 

1 

Section 

7. 

2 

1 

Section 

6 

2 

2 

2 

Section 

7  . 

2 

2.3 

Section 

6 

4 

1 

Section 

7  . 

4 

1 

Section 

6 

4 

2 

Section 

7  . 

4 

2 

Section 

6 

4 

3 

Section 

7. 

4 

3 
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NETWORK  LAYER 

Editor's  Note:  The  term  "Ongoing"  used  in  this  document  refers  to  the 
Working  Implementation  Agreements  dated  September  1990. 


3.1  INTRODUCTION 

This  chapter  presents  agreements  for  providing  the  OSI  network 
service.     Also  contained  here  are  agreements  on  network  layer 
addressing  and  routing. 


3.2     SCOPE  AND  FIELD  OF  APPLICATION 


These  agreements  cover  both  connectionless -mode  and  connection-mode 
network  services. 


3.3  STATUS 

This  version  of  the  agreements  was  completed  in  December  1989. 
Additional  material  in  3.8  has  been  included  since  then.     Part  of  this 
material  had  been  in  3.13  of  the  Working  Document. 


3.4  ERRATA 

Editor's  Note:  This  section  may  contain  "Defect  Report"  and 

resolutions  material,  and  the  versions  of  implementor 
agreements  to  which  this  material  aplplies. 

The  following  defects  are  being  progressed  in  ISO: 

-  ISO  9542,  defects  1-12. 


3.5     CONNECTIONLESS -MODE  NETWORK  SERVICE  (CLNS) 

3.5.1  ISO  8473 

1.   Subsets  of  the  protocol: 

o  Implementations  will  not  transmit  PDUs  encoded  using 
the  inactive  subset.  Received  PDUs  encoded  using  the 
inactive  subset  will  be  discarded. 

o        The  non- segmenting  subset  will  not  be  used. 

Implementations  will  not  generate  data  PDUs  without  a 
segmentation  part.     However,  implementations  will 
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receive  and  correctly  process  PDUs  which  do  not  contain 
the  segmentation  part. 

2 .  Mandatory  Functions : 

o        The  lifetime  parameter  shall  be  used  as  specified  in 
Clause  6.4  of  ISO  8473.     The  parameter  shall  have  an 
initial  value  of  at  least  three  times  the  network  span 
or    three  times  the  maximum  transit  delay  (in  units  of 
500  milliseconds),  whichever  is  greater. 

o        The  reassembly  timer  for  an  initial  PDU  at  the 

reassembly  point  shall  be  no  greater  than  the  largest 
value  of  all  lifetime  parameters  contained  in  all 
derived  PDUs. 

o        The  use/non-use  of  checksums  shall  be  capable  of  being 
configured.     The  default    setting  shall  be  non-use. 

o        If  the  implementation  supports  the  generation  of  an  ER 
PDU,  the  system  shall  insert  in  the  destination  address 
field  of  the  ER  PDU  the  contents  of  the  source 
address  field  of  the  PDU  that  generated  the  error. 

3.  Optional  Functions: 

o        The  Security  parameter  is  not  defined  by  these 

Agreements.     Implementations  shall  not  transmit  the 
parameter  except  where  defined  by  bilateral 
agreements . 

o        Partial  and  complete  source  routing  will  not  be 
supported.^ 

o       Partial  record  of  route  will  be  supported  by 
Intermediate  systems. 

o        ISO  8473  will  be  followed  with  respect  to  QOS. 


A  defect  exists  with  the  Partial  Source  Routing  option  which 
can  cause  PDUs  to  loop  in  the  network  until  their  lifetime 
expires . 

3-2 


June  1990  Stable 


o        For  systems  implementing  the  congestion  notification 
function,  the  following  applies. 

A  Globally  Unique  QOS  Maintenance  parameter  shall  be 
included  in  all  PDU  originated  by  End  Systems.  As 
specified  in  ISO  8473,  the  initial  value  of  the 
Congestion  Experienced  flag  (CE  flag)  within  the 
Globally  Unique  QOS  Maintenance  Parameter  shall  be  set 
by  the  originating  End  System  to  zero.     All  other  flags 
within  the  Globally  Unique  QOS  Maintenance  Parameter 
shall  be  set  based  on  the  specific  local  needs  of  the 
originating  End  System. 

Intermediate  systems  not  implementing  queue  length 
averaging  shall  leave  the  CE  flag  in  the  same  state  as 
it  was  received.     In  particular,  no  intermediate  system 
(IS)  shall  ever  clear  (set  to  zero)  the  CE  flag. 
.All  intermediate  systems  shall  monitor  all  incoming  and 
outgoing  queues  and  compute  average  queue  lengths  as 
shown  by  example  in    table  3.1.     The  averaging  is  done 
from  the  beginning  of  the  previous  cycle  to  the 
current  time.     A  cycle  begins  at  the  instant  of  the 
first  NSDU  arrival  after  an  idle  period. 

An  IS  should  set  the  CE  flag  in  all  NSDUs  forwarded  on 
a  queue  which  has  an  average  queue  length  greater  than 
one . 

The  queue  length  averaging  algorithm  computes  the 
average  queue  length  over  two  cycles,  where  the  two 
cycles  are: 

1)  the  "previous  cycle,"  which  is  the  interval 
from  when  the  IS  becomes  busy,  until  it 
becomes  idle  and  the  idle  ends  (indicated  by 
the  instant  the  first  packet  arrives  to  the 
idle  IS) ,  and 

2)  the  "current  cycle,"  which  is  the  interval 
from  the  end  of  the  idle  interval  to  the 
current  time  instant  when  the  average  queue 
length  is  computed. 

An  embodiment  of  the  averaging  algorithm  is  shown  in 
table  3.1. 
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Table  3.1.     Queue  Length  Averaging  Algorithm 


The  algorithm  makes  use  of  the  following  variables: 
t  =  Current  time 

tj^  =  time  of  i^^  arrival  or  departure  event 
qj^  =  number  of  packets  in  the  system  after  the  event 
Tq  =  time  at  the  beginning  of  the  previous  cycle 
T^  =  time  at  the  beginning  of  the  current  cycle 

The  algorithm  consists  of  three  components: 

1.  Queue  Length  Update:  Beginning  with  qo  =  0. 

If  the  i^^  event  is  an  arrival  event,        =  qi-i+l 
^•  i    .      If  the  i^^  event  is  a  departure  event,  q^  =  qi-i-l 

i    2 .  Queue  Area  (integral)  update: 

.       Area  of  the  previous  cycle  =  S    qi-l (ti-t^.j^) 

ti€{To,Ti) 

Area  of  the  current  cycle  =  Z    <li-l (^i-ti-i) 

tic{Ti,t) 

3 .  Average  Queue  Length  Update : 

:  >       .'      Average  Queue  length  over  the  two  cycles 

_    Area  of  the  two  cycles  _  Area  of  the  two  cycles 
Time  of  the  two  cycles  t-TQ 


o        (Refer  to  the  Ongoing  Implementation  Agreements 
document  for  additional  optional  functions) 

3.5.2  Provision  of  CLNS  over  Local  Area  Networks  (LANS) 

When  providing  CLNS  over  a  LAN  subnetwork,  the  following  shall 
apply: 

1.  The  definition  of  CLNS  shall  be  as  specified  in  ISO 
8348/Add.  1, 

2.  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473 
with  agreements  as  specified  in  3.5.1,  and 

1       -   3.       The  necessary  subnetwork  dependent  convergence  function 
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shall  be  as  defined  in  ISO  8473  -  Clause  8.5.1,  SNDCF 
used  with  ISO  8802/2  sub-networks . " 


3.5.3  Provision  of  CLNS  over  X.25  Subnetworks 

When  providing  CLNS  over  X,25  subnetworks,  the  following  shall 
apply: 

1.      The  definition  of  CLNS  shall  be  as  specified  in  ISO 
8348/Add.  1, 


2.  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473 
with  agreements  as  specified  in  3.5.1,  and 

3.  The  necessary  subnetwork    dependent  convergence 
function  shall  be  as  defined  in  ISO  8473  -  Clause 
8.5.2,   "SNDCF  used  with  ISO  8208  subnetworks  for 
operation  over  X.25  subnetworks,"    The  default 
throughput  class  shall  be  used  if  this  facility  is 
available,  and 

4.  The  X.25  PLP  shall  be  as  specified  in  section  2.6.3. 


3.5.4  Provision  of  CLNS  over  ISDN 

When  providing  CLNS  over  an  ISDN,  the  following  shall  apply. 


3.5.4.1      CLNP  Utilizing  X.25  Services 

o        The  definition  of  CLNS  shall  be  as  specified  in  ISO 
8348/Add.  1, 

o        The  protocol  used  to  provide  CLNS  shall  be  ISO  8473 
with  agreements  as  specified  in  section  3.5.1,  and 

o        The  necessary  Sub-network  Dependent  Convergence 
function  shall  be  as  defined  in: 

ISO  8473  for  operation  of  CLNP  over  X.25  with 
agreements  as  specified  in  section  3.5.3,  and 

ISO  9574  for  control  of  the  B  and  D  channels. 

Note:  The   stated   scope   of   ISO  9574  does  not 

explicitly  cover  the  operation  of  CLNP 
over  an  ISDN.  However,  the  procedure 
identified      for      operating     X.25  in 
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conjunction  with  1.451    is  still 
applicable.     The  procedures  in  ISO  9574 
that  correspond  to  8878  are  not  utilized 
when  providing  CLNS . 

o       The  X.25  PLP  shall  be  as    specified  in    section  2.6.3. 

o        The  agreements  for  the  ISDN-related  protocols  are 
specified  in  section  2.7. 


3.5.5  PROVISION  OF  CLNS  OVER  POINT-TO-POINT  LINKS 

(Refer  to  the  Ongoing  Implementation  Agreements 
document) . 


3.6     CONNECTION-MODE  NETWORK  SERVICE  (CONS) 

The  following  agreements  concern  provision  of  the  connection-mode 
Network  Service. 


3.6.1  Mandatory  Method  of  Providing  CONS 

3.6.1.1  General 

Independent  of  the  subnetwork  type  (of  sec.  2),  when 
providing  the  CONS  using  X. 25-1984,  the  following  shall 
apply  as  described  below. 

o  The  definition  of  the  CONS  is  as  specified  in  ISO  8348, 
Network  Service  Definition. 

o  The  mapping  of  the  elements  of  the  CONS  to  the  elements 
of  the  X.25  Packet  Layer  Protocol  (PLP)  is  as  specified 
in  section  3.6.3.1. 

o        The  general  procedures  and  formats  of  the  X.25  PLP  are 
as  specified  in  ISO  8208,  X.25  Packet  Layer  Protocol 
for  Data  Terminal  Equipment. 

3.6.1.2  X.25  WAN 

No  provisions  additional  to  those  in  section  3.6.1.1  apply 
in  an  X.25  WAN. 
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3.6.1.3  LANs 

When  providing  the  CONS  in  a  Local  Area  Network,  the 
following  aspects  of  ISO  8881,  in  addition  to  the  documents 
listed  in  section  3.6.1.1,  shall  apply: 

o        Clauses  1-6  and  9-11  for  LLC  Type  1  operation, 

including  the  additional  nonstandard  default  packet 
size  listed  in  Clause  6.3,  Note  2 

Note:  Operation  of  ISO  8208  in  conjunction  with  LLC 
Type  2  requires  agreement  on  LLC  Type  2 
procedures . 


3.6.1.4  ISDN 

When  providing  the  CONS  in  an  ISDN,  the  considerations  for 
control  of  a  B  and  D  channel  in  ISO  9574,  in  addition  to 
those  provided  in  section  3.6.1.1,  shall  apply. 


3.6.2  Additional  Option:     Provision  of  CONS  over  X.25  1980 
Subnetworks 

When  providing  CONS  over  an  X.25  1980  subnetwork,   the  following 
shall  apply: 

o        The  definition  of  the  CONS  is  as  specified  in  ISO  8348, 
Network  Service  Definition,  and 

o        The  subnetwork    dependent  convergence  protocol 

required  to  provide  CONS  shall  be  as  specified  in  ISO 
8878  Annex  A,  and  referred  to  as  the  Alternative 
Procedures  for  Network  Connection  Establishment  and 
Release .  with  agreements  as  defined  in  3.6.3.2. 

3.6.3  Agreements  on  Protocols 

3.6.3.1  ISO  8878 

ISO  8878  Clauses  1-11  shall  apply  with  the  following 
exception: 

o  Where  the  ISO  8208  diagnostic  codes  are  not  provided, 
all  Cause/Diagnostic  code  combinations  can  be  mapped 
to  the  Originator/Reason  code  of  "Undefined." 

3.6.3.2  Subnetwork  Dependent  Convergence  Protocol  (ISO 
8878/Annex  A) 
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o        The  Receipt  Confirmation  service  will  not  be  provided, 
so  the  corresponding  protocol  elements  need  not  be 
implemented . 

o        The  Expedited  Data  service  will  not  be  provided, 

so  the  corresponding  protocol  elements  need  not  be 
implemented. 


3.6.4  Interworking 

.  Interworking  between  subnetworks  whose  End  Systems  use  ISO  8208 
to  provide  the  CONS  as  specified  in  section  3.6.1  shall  be 
performed  as  specified  in  ISO  TR  10029.     That  is,  an  Intermediate 
System  connecting  two  such  subnetworks  shall  operate  ISO  8208  on 
both  subnetworks  and  shall  relay  information  from  one  subnetwork 
to  the  other  as  described  in  ISO  TR  10029. 

3.7  ADDRESSING 


NSAP  address  formats  supported  will  conform  to    Addendum  2  of  ISO 
8348. 

o        NSAP  address  formats  will  have  a  hierarchical  structure. 

This  will  reduce  the  size  of  routing  tables. 

o        If  used  in  the  Domain  Specific  Part  (DSP) ,  an  NSAP  selector 
shall  be  the  least  significant  component  in  the  hierarchy, 
and  shall  be  encoded  as  the  last  octet  of  the  DSP.  The  NSAP 
selector  shall  not  be  used  to    perform  routing;   it  is  simply 
intended  to  identify  the  network  service  user  at  the 
destination  end  system.     For  those  implementations  using  an 
NSAP  selector,  there  shall  be  one  and  only  one  selector 
for  each  NSAP  within  the  end  system.     All  NSAP  addresses 
identifying  a  given  NSAP  will  use  the  same  NSAP  selector 
value . 


3.8  ROUTING 


The  basic  principles  of  Network  Layer  routing  are  defined  in  the  OSI 
Routing  Framework  ISO  TR  9575.     These  principles  include: 

-        The  global  OSI  environment  will  consist  of  a  number  of 

Administrative  Domains.     An  Administrative  Domain  consists  of  a 
collection  of  End  Systems  (ES)  and  Intermediate  Systems  (ISs) , 
and  subnetworks  operated  by  a  single  organization  or 
Administrative  Authority.     The  Administrative  Authority  is 
responsible  for:     the  organization  of  ESs  and  ISs  into  Routing 
Domains;  the  assignments  of  NSAP  and  SNPA  addresses;  the  policies 
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that  govern  resource  usage;  the  policies  that  govern  the 
information  that  is  collected  and  disseminated  both  internally 
and  externally  to  the  Administrative  Domain;  and,  the 
establishment  of  subdomains  and  the  corresponding  delegation  of 
responsibilities . 

A  Routing  Domain  is  a  set  of  ESs  and  ISs  which  operate  according 
to  the  same  routing  procedures  and  which  is  wholly  contained 
within  a  single  Administrative  Domain.     An  Administrative 
Authority  may  delegate  to  the  entity  responsible  for  a  Routing 
Domain  the  responsibilities  to  further  structure  and  assign  NSAP 
and  SNPA  addresses.     The  hierarchical  decomposition  of  Routing 
Domains  into  subdomains  may  greatly  reduce  the  resources  required 
in  the  maintenance,  computation,  and  storage  of  routing 
information. 

The  OSI  routing  problem,  and  consequently  OSI  routing  protocols, 
has  been  decomposed  into  three  distinct  classes: 

End  System  (ES)  to  Intermediate  System  (IS)  routing  within  a 
single  subnetwork. 

IS  to  IS  routing  within  a  single  routing  domain  (Intra- 
domain) . 

IS  to  IS  routing  between  routing  domains  ( Inter- domain) . 

The -GSI -routing -problem -has -been -decomposed -into -two  -distinct  -classes 
of -routingt 

End -Systems -fES> -to -Intermediate -Systems -6IS> -routtngT 

IS-to-IS -routingT 
3.8.1  End  System  to  Intermediate  System  Routing 

For  use  in  conjunction  with  ISO  8473  over  LANs  (refer  to  sec. 
2.5)  and  point-to-point  links,  ISO  9542  shall  be  used  to 
provide  the  routing  exchange  protocol. 

Additionally,  a  management  mechanism  capable  of  adding  and 
deleting  entries  into  the  Routing  Information  Base  (RIB)  is 
recommended.     When  using  the  management  mechanism  to  add  an 
entry,  there  should  be  no  holding  timer,  and  the  entry  should  be 
write  protected  from  alteration  by  the  ES-IS  protocol.  This 
mechanism  enables  routing  table  entries  to  be  made  which  are 
static  in  nature. 

The  agreements  below  apply  to  the  use  of  ISO  9542. 
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1.  Implementors  shall  support  any  valid  NSAP  format.  For 
the  purposes  of  the  protocol,  NSAP  addresses  are 
treated  simply  as  octet  strings. 

2.  For  LANs,  implementors  shall  support  both 
Configuration  Information  and  Route  Redirection 
Information;  no  subsets  are  permitted. 

3.  All  timer  values    shall  be  configurable. 

4.  Use  or  non-use  of  checksums  shall  be  configurable.  It 
is  recommended  not  to  use  ISO  9542  checksums  when 
originating  PDUs. 

5.  The  QOS ,  Security  and  Priority  parameters  should  not  be 
used  for  routing.     For  conformance,  intermediate 
systems  must  transmit  these  parameters  in  RD  PDUs  if 
they  are  present  in  the  data  PDU  which  generated  the 
redirect.     However,  end  systems  must  ignore  them  in 
received  RD  PDUs. 


6.      If  the  configuration  notification  function  described 
in  clause  6.7  of  the  protocol  specification  is 
implemented,  a  mechanism  shall  be  provided  to 
enable/disable  this  function  on  broadcast  networks.  If 
supported  in  end  systems  listening  to  both  ISHs  and 
ESHs ,  this  function  shall  only  be  invoked  upon  receipt 
of  an  ISH. 

An  alternative  mechanism  for  achieving  rapid 
configuration  which  is  scaleable  to  large  broadcast 
networks  is  described  below.     This  mechanism  makes  use 
of  the  Suggested  ES  Configuration  Timer. 
Implementation  of  this  mechanism  is  optional. 

IS  Actions 


a)       IS  Actions 

When  an  Intermediate  system  wants  to  quickly  acquire 
the  End  system  configuration  (for  example,  when  a 
broadcast  circuit  is  enabled  on  the  IS  or  the  topology 
changes  because  of  a  failure  of  a  bridge  or  repeater) , 
it  initiates  a  "poll"  of  the  End  system  configuration 
by  performing  the  following  actions: 

1.       Delay  a  random  interval  between  0  and 

PollESHelloRate  seconds.     (This  is  to  avoid 
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synchronization  with  other  ISs  which  have  detected 
a  change . ) 

2.       In  order  to  rapidly  time  out  any  End  systems  which 
are  no  longer  present  on  the  broadcast  circuit 
(for  example,  after  a  LAN  partition),  reset  the 
entryRemainingTime  in  the  Routing  Information  Base 
for  all  End  systems  on  this  circuit  to  the  value: 

(ISHelloTimer  +  PollESHelloRate)  *  HoldingMultiplier 

or  the  existing  value  whichever  is  lowest.  Where 
ISHelloTimer  is  the  Intermediate  system's  configuration 
timer,  HoldingMultiplier  is  a  predefined  number  (for 
example,  2)  which  multiplied  by  ISHelloTimer  gives  the 
value  for  the  Holding  Time  field  of  IS  Helios. 

3..     Then  transmit  HoldingMultiplier  IS  Helios  with  a 
Suggested  ES  Configuration  Timer  value  of 
PollESHelloRate  seconds  with  an  interval  of 
ISHelloTimer  seconds  between  each  and  setting  the 
Holding  Time  field  to  ISHelloTimer  * 
HoldingMultiplier. 

4.      Then  start  sending  IS  Helios  with  a  Suggested  ES 
Configuration  Timer  of  DefaultESHelloRate  seconds 
(where  DefaultESHelloRate  is  larger  than 
PollESHelloRate) . 

b)      ES  Actions 

An  End  system  maintains  for  each  circuit  a  list 
(CTList)  which  has  HoldingMultiplier  elements  each  of 
which  stores  a  received  value  of  the  Suggested  ES 
Configuration  Timer.     The  function  SaveCT(t)  adds  the 
value  t  as  the  first  element  of  CTList  and  discards  the 
last  element.     The  function  MinCT  delivers  the  minimum 
value  in  CTList.     When  the  circuit  is  enabled  all  the 
elements  of  CTList  are  initialized  to  PollESHelloRate. 

An  End  system  also  maintains  for  each  circuit  the 
variables  currentSuggestedHelloTimer  and  its  associated 
lifetime  currentSuggestedHelloTimerLifetime .     These  are 
both  initialized  to  PollESHelloRate. 

When  the  circuit  is  enabled  the  Configuration  Timer  is 
started  by  setting  the  entryRemainingTime  to  random 
(PollESHelloRate) . 


3-11 


June  1990  Stable 


On  Configuration  Timer  expiry  the  following  actions  are 
performed: 

1.  SaveCT(currentSuggestedHelloTimer) . 

2.  Transmit  an  ES  Hello  with  Holding  Time  field  set 
to  MinCT  *  HoldingMultiplier . 

3.  Set  entryRemainingTime  to  MinCT  -  random(MinCT  * 
0.25).     (The  random  element  ensures  that  End 
systems  do  not  become  synchronized.) 

When  an  End  system  receives  an  IS  Hello  which  contains 
a  Suggested  ES  Configuration  Timer,  it  is  processed  as 
follows  (where  suggestedESCT  is  the  value  contained  in 
the  option) : 

1.  If  suggestedESCT  is  less  than  or  equal  to 
currentSuggestedHelloTimer  then  set 
curentSuggestedHelloTimerLifetime  to  the  value  of 
the  Holding  Time  field  of  the  IS  Hello. 

2.  If  suggestedESCT  is  less  than 
currentSuggestedHelloTimer  then  set 
currentSuggestedHelloTimer  to  suggestedESCT  and 
reset  entryRemainingTime  to  the  smaller  of  its 
current  value  and 

random(currentSuggestedHelloTimer  *  0.75). 

When  the  currentSuggestedHelloTimerLifetime  expires, 
set  the  currentSuggestedHelloTimer  to 
DefaultESHelloTimer. 


For  LANs,   this  protocol  employs  the  same  LSAP  as  ISO 
8473. 

The  encoding  of  the  BSNPA  address  follows  the  syntax 
rules  for  the  data  link  being  used.     On  a  LAN,  for 
example,   it  is  a  48-bit  MAC  address. 

The  multicast  addresses  corresponding  to  "all 
intermediate  systems  on  the  network"  (ALL_ISN)  and  "All 
End  Systems  on  the  Network"  (ALL_ESN)  shall  default  to 
the  following  on  IEEE802.3  and  IEEE802.4  subnetworks: 

ALL_ESN  =  0900  2B00  0004 
ALL  ISN  =  0900  2B00  0005 
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It  is  understood  that  the  hexadecimal  octets  shown  are 
transmitted  onto  the  medium  form  left  most  octet  to 
right  most  octet.     Within  each  hexadecimal  octet  the 
least  significant  bit  is  transmitted  first. 

10.  The  multicast  addresses  corresponding  to  "All 
Intermediate  Systems  on  the  network"  (ALL  ISN)  and  "All 
End  systems  on  the  Network"  (ALL_ESN)  shall  default  to 
the  following  two  functional  addresses  on  IEEE802.5 
subnetworks : 

ALL_ESN  =  COOO  0000  4000 
ALL_ISN  -  COOO  0000  8000 

It  is  understood  that  the  hexadecimal  octets  shown  are 
transmitted  onto  the  medium  from  left  most  octet  to 
right  most  octet.     Within  each  hexadecimal  octet  the 
most  significant  bit  is  transmitted  first." 

9t      For  -LANs ,-  -the  -muttieast  -addresses  -corresponding  -to  -'^AH 
Intermediate  -Systems  -on  -the  -network'^  -(^Al:l:_;ISN)-  -and  -'^AH 
End  -Systems  -on  -the  -network'^  -(■A]:1:^ESN>  -shall  -default  -to 
the  -f  oHowingf 

AH^ESN  -=-  -0900  -2BGG  -0004 
AH^ISN  -=-  -0900  -2BG0  -0005 

Note  i  Vers  ion  - 1 7  -  Edition-  4-  -of-  -the&e-  -agreements  -had 
the  -  above-  -addr-esses-  -  reversed-  -<4-.e-.-,-  -Alt^ISN 
was  -given  -as  -0900  -2B00  -0004 ,-  -etc  .->  -because  -of 

an  -  -  unintentional  er-r-or^  -  -  in-  -  <:he  original 

proposal .-  There  -  -is-  -  no-  -intent  -  -to-  -maintain 

compatibility  -  with-  -sys-t-ems-  -  using  -  -Ver-sion-  -  ty 
Edition  -1 -addressesv 

For  -IEEE  -802  .-3  -and  -802  .-4  -LANs ,-  -it  -is  -understood  -that 
the  -hexadecimal -octets -shown -are -transmitted  -onto  -the 
medium  -from  -left-most  -octet  -to  -right-most  -octet  .-- 
Within  -each  -hexadecimal  -octet ,-  -the  -least  -significant 
bit  -is  -transmitted -first 7 

11.  The  Error  Report  flag  shall  be  set  to  zero  (0)  for 
NPDUs  sent  as  a  result  of  invoking  the  QUERY 
Configuration  Function. 

2  Intermediate  Systems  to  Intermediate  Systems  Routing 


3-13 


June  1990  Stable 


Intermediate  systems  shall  provide  mechanisms  to  create  and 
update  the  required  Routing  Information  Base. 

PROCEDURES  FOR  OS I  NETWORK  SERVICE/PROTOCOL  IDENTIFICATION 

3.9.1  General 

The  Protocol  Identifiers  specified  in  ISO  DTR  9577  ("Protocol 
Identification  in  the  OSI  Network  Layer")  provide  a  basis  from 
which  OSI  systems  (both  end  systems  and  intermediate  systems)  may 
derive  a  set  of  procedures  for  indicating  which  OSI  protocols  are 
used  in  a  particular  instance  of  communication.     As  such,  these 
procedures  are  only  concerned  with    Initial  Protocol  Identifiers 
(IPIs)  and    Subsequent  Protocol  Identifiers  (SPIs)  that  identify 
OSI  protocols  and  pertain  to  the  following  types  of  systems: 

A.       systems  providing/supporting  only  CONS  (using  ISO 
8208/8878) , 

:  B.       systems  providing/supporting  only  CLNS  (using  ISO 
8473),  and 

C.       systems  providing/supporting  both  CONS  and  CLNS. 

From  this  set  of  definitions,  the  following  possibilities  for 
success  (S)  or  failure  (F)  of  an  instance  of  communication  can  be 
defined,  as  shown  in  the  table  below: 


Table  3.2.     End  Systems  Communications 


Originating 

Destination 

End  System  Type 

End  System  Type 

A 

B 

c 

A 

S 

F 

S 

B 

F 

S 

s 

C 

S 

S 

S 

3.9.2         Processing  of  Protocol  Identifiers 

The  usage  of  Protocol  Identifiers  in  Network  Protocol  Data  Units 
(NPDUs)  depends  on  several  factors: 

the  OSI  Network  Service  to  be  provided, 
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the  protocol  to  be  used  in  providing  this  service, 

the  role  the  protocol  is  to  be  used  in  (per  the  Internal 

Organization  of  the  Network  Layer) , 

and 

the  type  of  subnetwork  to  which  the  system  is  connected. 
3.9.2.1      Originating  NPDUs 

The    use  of  a  particular  OSI  Network  Service  depends  on  the 
capabilities  of  both  the  origination  and  destination  end 
systems.     It  is  not  the  intent  of  this  section  to  provide 
guidelines  on  how  to  make  this  choice  except  for  simple 
obvious  criteria;  rather,  it  is  intended  only  to  provide 
guidance  on  how  to  convey  this  choice  to  the  destination 
system. 

Where  a    priori  knowledge  exists  in  the  originating  end 
system  about  the  capabilities  (with  respect  to  OSI  Network 
Services  available)  of  the  destination  end  system,  it  should 
be  used.     This  may  result  in  no  communication  if  the  two  end 
systems  involved  only  provide  Network  Services  of  different 
types.     A  selection  is  required  in  cases  where  both  end 
systems  provide  both  types  of  network  services;  this 
selection  is  conveyed  by  the  use  of  the  IPI  and  SPI  (but  the 
selection  process  is  an  implementation  matter) . 
Alternatively,  where  a    priori  knowledge  does  not  exist, 
then  the  selection  of  a  service  to  use  in  an  instance  of 
communication  depends  solely  on  the  capabilities  of  the 
originating  end  system  as  described  below. 

If  only  CONS-related  protocols  (e.g.,  ISO  8208)  are 
available,  then  this  should  be  used  and  the  Protocol 
Identifiers  specified  so  as  to  reflect  the  chosen 
protocol(s)  and  service. 

If  only  CLNS-related  protocols  (e.g.,  8473)  are 
available,  then  this  should  be  used  and  the  Protocol 
Identifiers  specified  so  as  to  reflect  the  chosen 
protocol(s)  and  service. 

If  both  services  are  available,  then  other  criteria  are 
used  in  deciding  which  to  use  in  an  instance  of 
communication. 

Note:  The  choice  of  OSI  Network  Service  to  be  used  in  an 
instance  of  communication  is  reflected  in  the 
Network  Service  primitives  issued  by  the  Network 
Service  user. 
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Once  a  selection  of  Network  Service  has  been  made,   the  use 
of  particular  protocols  depend  on,  for  example,  the 
subnetwork  to  which  the  originating  End  System  is  attached. 
Some  specific  cases  are  given  in  Annex  A  of    ISO  DTR  9577. 
Another  case  involves  use  of  the  Protocol  for  Providing  the 
Connectionless  Network  Service  directly  over  the  Data  Link 
Service,  as  given  in  ISO  8473  (e.g.,   in  a  LAN).     In  this 
case,   the  IPI  indicates  ISO  8473. 


3.9.2.2      Destination  System  Processing 

A  system  receiving  an  NPDU  must  first  be  concerned  with  the 
protocol  identified  by  the  IPI.     Valid  values  are  given  in 
table  2  of    ISO  DTR  9577.     If  the  protocol  is  recognized  as 
one  supported  by  the  system,  further  processing  of  the 
protocol  is    performed  according  to  the  rules  of  that 
protocol.     If  not,  an  error  is  recognized  and  may  be 
conveyed  to  the  originating  peer  entity.     With  respect  to 
ISO  8208  and  ISO  8473,  the  following  would  apply  for  such 
error  conditions. 

1.  For  ISO  8208,  the  condition  is  classified  as  an 
"invalid  General    Format  Identifier,"  for  which  a 
DIAGNOSTIC  packet  may  be  returned.     If  DIAGNOSTIC 
packets  are  not  used  by  the  system,  the  NPDU  is 
discarded  without  any  further  action. 

2.  For  ISO  8473,  the  NPDU  is  discarded  without  any 
further  action. 

Given  acceptance  of  the  protocol  identified  by  the  IPI,  the 
system  must  also  determine  the  acceptability  of  the 
subsequent  protocols  and  OSI  Network  Service  being 
requested.     Use  of  ISO  8473  implies  CLNS ;  however,  use  of 
ISO  8208  can  imply  either  CONS  or  CLNS,  as  identified  by  the 
SPI .     In  the  case  of  ISO  8208,  therefore,  further  processing 
is  needed  to  determine  the  acceptability  of  the  requested 
protocol/service.     If    these  are  not  acceptable  (e.g.,  not 
supported  by  the  system) ,  the  call  should  be  cleared  with  a 
diagnostic  code    of  "Connection  Rejection  -  unrecognizable 
protocol  identifier  in  user  data"  (decimal  249) . 

Note:  In    ISO    8208,    a    call    may    be    refused  for 

reasons  other  than  non- support  of  the 
requested  OSI  Network  Service. 
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3.9.2.3      Further  Processing  in  Originating  End  System 

Further  processing  on  receipt  of  an  NPDU  in  response  to  an 
initial  attempt  to  communicate  may  be  necessary /useful  to 
determine  the  success  of  such  an  attempt. 

For  ISO  8473,  when  used  directly  over  the  Data  Link  Service, 
the  success  or  failure  of  an  attempt  to  communicate  may  not 
be  visible/obvious  within  the  Network  Layer.     On  the  other 
hand,  use  of  ISO  8473  over  ISO  8208  may  provide,  via  the 
diagnostic  code  in  a  received  CLEAR  INDICATION  packet,  an 
indication  of  failure  to  communicate  (e.g.,  the  remote 
system  does  not  support  CLNS). 

When  using  ISO  8208  to  provide  the  CONS,  the  diagnostic  code 
in  a  received  CLEAR  INDICATION  packet  may  provide  the 
necessary  indication  of  why  a  call  was  refused. In  cases 
where  an  ISO  8208  call  is  refused  with  diagnostic  #249,  it 
would  not  be  desirable  to  re-attempt  such  calls  with  the 
exact  same  set  of  parsimeters ;  however,  how  the  originating 
system  ensures  this  is  a  local  matter. 

In  cases  where  an    originating  system  is  capable  of 
supporting  both  OSI  Network  Services,  it  may  wish  to  re- 
attempt  communications  using  the  other  mode  of  Network 
Service  than  that  initially  attempted. 

3.9.3  APPLICABLE  PROTOCOL  IDENTIFIERS 

The  protocol  identifiers  applicable  to  these  agreements  are  given 
in  table  3.1  and  table  3.2. 


Table  3.1.     IPI  Values 


Bit  Pattern 
87654321 

Protocol 

00001000 
1    0    0    0    0    0    0  1 
10000010 

X      X      0      1      X      X  X 

xxl  Oxxxx 
OOllxxxx 

CCITT  I.451/Q.931 

ISO  8473  (excluding  the 

inactive  subset) 

ISO  9542 

ISO  8208/CCITT  X.25-Modulo  8 
ISO  8208/CCITT  X.25-Modulo  128 
ISO  8208/CCITT  X.25-GFI  Extension 
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Table  3.2.     SPI  Values 


Bit  Pattern  * 
8    7    6    5    4    3    2  1 

Protocol 

00000000 
thru 

0    0    1     1     1     1     1  i 

10000001 
10000100 

"  '  ■■ '■■  - 

ISO  8073  ADDl/CCITT  X.224 
See  table  4.1 

ISO  8473 

ISO  8878/Annex  A 

*  A  null  SPI  value  (e.g.,  no  Call  User  Data  Field  in  an 
ISO  8208/CCITT  X.25  Call  Request/Incoming  Call  packet) 
shall  indicate  ISO  8073/CCITT  X.224. 


When  using  ISO  8208,  values  other  than  one  of  those  listed  in 
table  3.2  are  outside  the  scope  of  these  agreements. 

3.10  MIGRATION  CONSIDERATIONS 

This  section  considers  problems  arising  from  evolving  OSI  standards 
and  implementations  based  on  earlier  versions  of  OSI  standards. 

3.10.1        X. 25-1980 

Until  there  is  widespread  availability  of  1984  X.25  service,  it 
will  be  necessary  for  X.400  systems  to  use  those  existing  packet- 
switched  public  data  networks  which  offer  only  pre- 1984  X.25 
service.     While  1980  X.25  does  not  provide  the  CONS  as  defined  by 
ISO  8348,  there  is  no  implication  of  non- conformance  to  these 
Agreements  resulting  there  from  for  systems  using  1980  X.25  to 
interchange  data  at  the  Network  Layer,  provided  they  conform  in 
all  other  respects. 

This  is  an  exception  to  the  Agreements  for  providing  the  OSI 
Network  Service,  granted  temporarily  for  practical  reasons.  This 
exception  will  be  removed  when  it  is  deemed  to  be  no  longer 
necessary,  in  the  judgement  of  the  Workshop.    While  this 
provision  is  in  effect,   it  provides  an  alternative  method  of 
using  1980  X.25  to  the  provisions  of  3.6.2. 
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3.11  USE  OF  PRIORITY 

(Refer  to  the  Ongoing  Implementation  Agreements  document) . 


3.11.1  INTRODUCTION 


(Refer  to  the  Ongoing  Implementation  Agreements 
document) . 


3.11.2  OVERVIEW 


(Refer  to  the  Ongoing  Implementation  Agreements 
document) . 


3.12  CONFORMANCE 

(Refer  to  the  Ongoing  Implementation  Agreements  document) , 
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4^  TRANSPORT 

Editor's  Note:  The  term  "Ongoing"  used  in  this  section  refers  to  the 
Working     Implementation     Agreements     document  dated 
I  September  1990. 

4.1  INTRODUCTION 

These  agreements  support  the  integration  of  LANs,  packet  networks,  and 
other  WANs  with  the  smallest  possible  set  of  mandatory  protocol  sets, 
in  accordance  with  the  other  agreements  already  reached.     Nothing  here 
shall  preclude  vendors  from  implementing  protocol  suites  in  addition 
to  the  ones  described  in  this  document. 


4.2     SCOPE  AND  FIELD  OF  APPLICATION 

This  chapter  presents  agreements  for  providing  the  OSI  Transport 
layer  services  over  both  connection  mode  and  connection- less  mode 
services . 


4.3  STATUS 


Completed  December  1989. 
4.4  ERRATA 


4.5     PROVISION  OF  CONNECTION  MODE  TRANSPORT  SERVICE 

Three  connection  mode  protocol  classes  have  been  identified  for 
implementation.     Transport  classes  0,  2  and  4  of  X.224  (1988)^  have 
been  endorsed  for  use  over  CONS.     Only  Transport  Class  4  of  ISO 
8073/Add.  2^  has  been  endorsed  for  use  over  CLNS.     The  following  class 
combinations  are  endorsed  for  CONS:   (0),   (0,2)  or  (0,2,4). 


^  Where  a  CR  TPDU  proposing  Class  2  or  4  is  initiated.  Class  0 
shall  be  explicitly  indicated  as  an  alternative  class  except  if 
there  is  already  one  (or  several)  transport  connection(s) 
assigned  to  the  network  connection  (multiplexing  being  possible) . 

2  In  general,  references  to  ISO  8073  in  ISO  8073/Add.  2  should  be 
interpreted  as  applying  to  X.224  (1988);  however,  the  reference 
to  Clause  14. 6.  a  in  Clause  14  of  ISO  8073/Add.  2  should  be 
interpreted  as  a  reference  to  Clause  14. 5. a  of  X. 224(1988). 
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4.5.1.1  Transport  Class  4  Overvlev 

Transport  Class  4  is  mandatory  for  communication  between 
systems  using  the  OSI  CLNS  and  may  also  be  used  for  systems 
using  the  OSI  CONS  (e.g.,  a  private  MHS ,  etc.). 

4.5.1.2  Protocol  Agreements 

A  disconnect  request  shall  be  issued  in  response  to  a 
connect  request  when  the  maximum  number  of  Transport 
connections  is  reached  or  exceeded. 


4.5.1.2.1  General  Rules 

o        All     implementations  shall  request  "use  of 

extended  formats"  in  the  CR  TPDU.  Implementations 
shall  accept  the  "use  of  extended  formats"  in  the 
CC  TPDU  if  it  was  proposed  in  the  CR  TPDU. 
Implementations  shall  accept  "use  of  normal 
formats"  if  it  was  proposed  in  the  CR  TPDU. 

o        Negotiation  of  protection  is  outside  the  scope  of 
these  agreements.     If  negotiation  of  protection 
is  not  supported,  receipt  of  the  protection 
parameters  in  CR  TPDU  and  CC  TPDU  shall  be 
ignored. 

o        Implementations  shall  be  capable  of  proposing  and 
accepting  the  non-use  of  checksums. 

o        Use  of  the  acknowledgment  time  parameter  is 

optional.  If  an  implementation  is  operating  any 
policy  which  delays  the  transmission  of  AK  TPDUs , 
the  maximum  amount  of  time  by  which  a  single  AK 
TPDU  may  be  delayed  shall  be  indicated  to  the  peer 
Transport  service  provider  using  the 
acknowledgment  time  parameter.     The  value 
transmitted  should  be  expressed  in  units  of 
milliseconds  and  rounded  up  to  the  nearest  whole 
millisecond. 

o        QoS  negotiation  is  outside  the  scope  of  these 

agreements.  If  QoS  negotiation  is  not  supported, 
receipt  of  the  parameters  "throughput,"  "residual 
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error  rate,"  "priority,"  and  "transit  delay"  in 
the  CR  and  CC  TPDUs  shall  be  ignored. 

o        It  is  recommended  that  implementations  not  send 
user  data  in  the  CR  TPDU  or  the  CC  TPDU.  The 
disposition  of  any  user  data  received  in  a  CR  TPDU 
or  CC  TPDU  is  implementation  dependent. 

o        It  is  recommended  that  implementations  not  send 

user  data  in  the  DR  TPDU.  The  disposition  of  any 
user  data  received  in  a  DR  TPDU  is  implementation 
dependent . 

o        An  unknown  parameter  in  any  received  CR  TPDU  shall 
be  ignored. 

o        A  Transport  entity  shall  accept  a  DR  TPDU  and  a 
corresponding  DC  TPDU  with  or  without  a  checksum 
in  response  to  a  CR  or    CC  TPDU. 

o        Transmitted  DR  TPDUs  shall  carry  a  disconnect 

reason  code    which  pertains  to  the  actual  cause  of 
the  disconnect.     A  DR  TPDU  may  carry  a  reason  code 
of  "0"   (unspecified)     if  an  appropriate  reason 
code  is  not  defined. 


o        Known  parameters  with  valid  lengths  but  with 

invalid  values  in  a  CR  TPDU  shall  be  handled  as 
follows : 


Parameter 
TSAP  id 
TPDU  size 
Version 
Checksum 

Alternate  Protocol 
Classes 


Action 
Send  DR  TPDU 
ignore  parameter, 
ignore  parameter, 
discard  CR  TPDU 
Protocol  Error 


use  default 
use  default 


o        Unrecognized  or  not  applicable  bits  of  the 

Additional  Options  parameter  shall  be  ignored. 

4.5.1.2.2  TRANSPORT  CLASS  4  SERVICE  ACCESS  POINTS  OR 
SELECTORS 


If  present,   the  TSAP  Id.   field  in  the  CR  and  CC  TPDUs 
shall  be  encoded  as  a  variable  length  field  and  will  be 
interpreted  as  an  octet  string.     The  length  of  the 
string  cannot  exceed  32  octets. 
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4.5.1.2.3  Retransmission  Timer 

It  is  recommended  that  the  value  used  for  the 
retransmission  timer  be  based  upon  the  round- trip  delay 
experienced  on  a  transport  connection.  The 
implementation  should  maintain,  and  continually  update, 
an  estimate  of  the  round- trip  delay  for  the  TC.  From 
this  estimate,  a  value  for  the  retransmission  timer  is 
calculated  each  time  it  is  started.     An  example 
technique  for  maintaining  the  estimate  and  calculating 
the  retransmission  timer  is  described  below.  The 
value  of  the  retransmission  timer  may  be  calculated 
according  to  the  following  formula: 

Tl  <         kE  +  AR 

In  this  formula,  E  is  the  current  estimate  of  the 
round- trip  delay  on  the  transport  connection,  AR  is 
the  value  of  the  acknowledgement  time  parameter 
received  from  the  remote  transport  service  provider 
during  connection  establishment,   and  k  is  some  locally 
administered  factor. 

A  value  for  k  should  be  chosen  to  keep  the 
retransmission  timer  sufficiently  small  such  that  lost 
TPDUs  v;ill  be  detected  quickly,  but  not  so  small  that 
false  alarms  are  generated  causing  unnecessary 
retransmission . 

The  value  of  E  may  be  calculated  using  an  exponentially 
weighted  average  based  upon  regular  sampling  of  the 
interval  between  transmitting  a  TPDU  and  receiving  the 
corresponding  acknowledgment.     Samples  are  taken  by 
recording  the  time  of  day  when  a  TPDU  requiring 
acknowledgment  is  transmitted  and  calculating  the 
difference  between  this  and  the  time  of  day  when  the 
corresponding  acknowledgment  is  received.     New  samples 
are  incorporated  with  the  existing  average  according  to 
the  following  formula. 

E  <         E  +  (1  -  a)(S  -  E) 

In  this  formula,  S  is  the  new  sample  and  a  is  a 
parameter  which  can  be  set  to  some  value  between  0  and 
1.     The  value  chosen  for  a  determines  the  relative 
weighting  placed  upon  the  current  estimate  and  the  new 
sample.  A  large  value  of  a  weights  the  old  estimate 
more  heavily  causing  it  to  respond  only  slowly  to 
variations  in  the  round- trip  delay. 
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A  small  value  weights  the  new  sample  more  heavily 
causing  a  quick  response  to  variations.    (Note  that 
setting  Q  to  1  will  effectively  disable  the  algorithm 
and  result  in  a  constant  value  for  E,  being  that  of  the 
initial  seed.) 

If  a  is  set  to  1-2"^  for  some  value  of  n,   the  update 
can  be  reduced  to  a  subtract  and  shift  as  shown  below. 

E  <         E  +  2'"  (S  -  E) 

When  sampling,   if  an  AK  TPDU  is  received  which 
acknowledges  multiple  DT  TPDUs ,   only  a  single  sample 
should  be  taken  being  the  round- trip  delay  experienced 
by  the  most  recently  transmitted  DT  TPDU.  This 
attempts  to  minimize  in  the  sample  any  delay  caused  by 
the  remote  transport  service  provider  withholding  AK 
TPDUs . 


4.5.1.2.4  Keep-Alive  Function 

The  Class  4  protocol  detects  a  failed  Transport 
connection  by  use  of  an  'inactivity  timer'.     This  timer 
is  reset  each  time  a  TPDU  is  received  on  a  connection. 
If  the  timer  ever  expires,   the  connection  is 
terminated . 

The  Class  4  protocol  maintains  an  idle  connection  by 
periodically  transmitting  an  AK  TPDU  upon  expiration  of 
the   'window  timer'.  Thus,   in  a  simple  implementation, 
the  interval  of  one  transport  entity's  window  timer 
must  be  less  than  that  of  its  peer's  inactivity  timer, 
and  vice  versa.     The  following  agreements  permit 
communicating  transport  entities  to  maintain  an  idle 
connection  without  shared  information  about  timer 
values . 

o        In  accordance  with    ISO  8073/X.224,  Clause 

12. 2. 3. 9. a,  all     implementations  must  respond  to 
the  receipt  of  a  duplicate  AK  TPDU  not  containing 
FCC  by  transmitting  an  AK  TPDU  containing  the 
'flow  control  confirmation'  parameter. 
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o        Implementations  must  always  transmit  duplicate  AK 
TPDUs  without  FCC  on  expiration  of  the  local 
window  timer  (see     ISO  8073/X.224,  Clause 
12.2.3.8.1).     Receipt  of  this  TPDU  by  the  remote 
Transport  entity  will  cause  it  to  respond  with  an 
AK  TPDU  containing  the  'flow  control  confirmation' 
parameter.     When  this  is  received  by  the  local 
transport  entity,   it  will  reset  its  inactivity 
timer.     See  figure  4.1. 

o        It  is  a  local  matter  for  an  implementation  to  set 
the  intervals  of  its  timers  to  appropriate 
relative  values.  Specifically: 

o        The  window  timer  must  be  greater  than  the 
round- trip  delay.     See  section  4.5.1.2.3. 

o        The  inactivity  timer  must  be  greater  than  two 

times  the  window  timer;  and  should  normally  be  an 
even  greater  multiple  if  the  Transport  connection 
is  to  be  resilient  to  the  loss  of  an  AK  TPDU. 

A  duplicate  AK  TPDU  (See  fig.  4.1)  is  one  which 
contains  the  same  values  for  YR-TU-NR,  credit,  and 
subsequence  number  as  the  previous  AK  TPDU  transmitted. 
A  duplicate  AK  TPDU  does  not  acknowledge  any  new  data, 
nor  does  it  change  the  credit  window. 
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Figure  4.1.     AK  exchange  on  idleconnection. 


4.5.1.2.5  Congestion  Avoidance  Policies 

This  section  defines  both  mandatory  and  optional 
requirements  relating  to  avoiding  congestion  in  OSI 
networks  and  recovering  from  it  when  it  is 
experienced.     The  mandatory  requirements  specify  a 
minimum  approach  to  congestion  avoidance/recovery 
which  can  be  tuned  based  upon  the  specific 
requirements  of  the  network.     The  optional 
requirements  specify  a  dynamic  window  sizing  scheme 
which,   if  implemented,  will  contribute  further  to  the 
avoidance  of  congestion  in  the  network. 

Mandatory  Requirements 

1        A  maximum  size  for  the  "receive  credit  window," 

the  value  of  which  is  locally  configurable,  should 
be  provided.  A  "receive  credit  window"  reflects 
the  number  of  credits  sent  by  a  Transport  entity 
for  a  Transport  connection.  The  maximum  size  of 
the  "receive  credit  window"  shall  be  referred  to 
as  WR^, 
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2  A  maxiimam  size  for  the  "sending  credit  window," 
the  value  of  which  is  locally  configurable,  shall 
be  provided.  A  "sending  credit  window"  reflects 
the  number  of  data  TPDUs  that  a  Transport  entity 
is  willing  to  send  on  a  Transport  connection.  The 
maximum  size  of  the  "sending  credit  window"  shall 
be  referred  to  as  WS^.     As  specified  in  ISO  8073, 
the  "sending  credit  window"  shall  also  be  less 
than  or  equal  to  the  remote  "receive  credit 
window"  as  conveyed  in  the  last  CDT  field. 

3  It  is  strongly  recommended  that  an  implementation 
use  a  retransmission  timer  per  Transport 
connection.     If,  upon  expiration  of  the 
retransmission  timer,  an  implementation  allows 
more  than  "1"  TPDU  to  be  transmitted  a  means  to 
locally  adjust  the  maximum  number  shall  be 
provided. 

4  All  implementations  shall  have  the  capability  of 
operating  without  delaying  ACKs  of  data  TDPUs 
received  in-sequence  (i.e.,  Al  essentially  equals 
zero) .     If  an  implementation  optionally  chooses  to 
explicitly  delay  ACKs,  a  means  to  locally  adjust 
Al  shall  be  provided. 

Optional  Requirements 

For  systems  implementing  the  dynamic  window  sizing 
scheme  the  following  rules  apply  as  described  below. 

RECEIVING  TRANSPORT  ENTITY  (RTE)  RXJLES: 

Rule  1:      Initialization  of  Window 

The  initial  value  of  WR  (known  as  WRq)  shall 
have  a  locally  configurable  upper  bound. 
This  window  is  sent  to  the  sending  transport 
entity  (STE)  in  the  next  CDT  field 
transmitted. 

Rule  2:       Required  Sampling  Period 

All  RTEs  shall  maintain  a  fixed  value  for  WR 
until  the  next  2WR  DT  TPDU  arrive  since  the 
last  CDT  field  was  transmitted  by  the  RTE. 

Rule  3:       Required  Counting  of  Received  TPDUs  in  a 
Sampling  Period 
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All  RTEs  shall  maintain  a  count,  N  equal  to 
the  total  number  of  TPDUs  received  and  a 
count,  NC  equal  to  the  total  number  of  TPDUs 
received  which  had  the  CE  Flag  set.  All 
types  of  TPDUs  are  included  in  the  counts  for 
N  and  NC,  not  just  DT  TPDUs. 


Rule  4:       Required  Action  upon  the  end  of  a  Sampling 
Period 

All  RTEs  shall  take  the  following  action  at 
the  end  of  each  sampling  period: 

o        If  the  count  NC  is  less  than  50 
percent  of  the  count  N,  the  RTE 
shall  increase  WR  by  adding  1  up  to 
a  maximum,  WR^ ,    (that  is  based  on 
the  local  buffer  management  policy) 
otherwise,   it  shall  decrease  WR  by 
multiplying  by  0.875  (a  minimum  of 
1). 

o        Reset  N  and  NC  to  zero. 

o        Transmit  the  new  window  WR  in  the 
next  CDT  field  sent  to  the  sending 
transport  entity. 

SENDING  TRANSPORT  ENTITY  (STE)  RULES 

Rule  1:       Initialization  of  Window 

All  STEs  shall  maintain  a  sending  window  size 
(WS) .     Initially  and  also  as  long  as  there  is 
no  loss,  WS  is  set  equal  to  the  receiving 
window  value  WR  received  from  the  remote  RTE 
in  the  last  CDT  field. 

Rule  2:      Required  Action  on  a  Timeout 

All  STEs  shall  reset  WS  to  one  when  the 
retransmissions  timer  expires  and  indicates  a 
lost  TPDU.     WS  now  limits  the  number  of  DT 
TPDUs  that  may  be  transmitted  or 
retransmitted  without  further 
acknowledgments . 

Rule  3:       Required  Counting  of  Acknowledged  TPDU 
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All  STEs  shall  maintain  a  count ,  ACKRCVD  of 
the  number  of  DT  TPDUs  acknowledged,  by  the 
RTE ,  since  WS  was  last  adjusted.  Therefore 
each  time  WS  is  adjusted,  the  count  ACKRCVD 
shall  be  reset  to  zero. 

Rule  4:       Increase  Window  Policy 

All  STEs  shall  increase  WS  by  one  each  time 
ACKRCVD  is  equal  to  or  greater  than  the 
current  value  of  WS ,  unless  WS  exceeds  the 
window  permitted  by  the  remote  RTE. 


4.5.1.2.6  USE  OF  PRIORITY 

(Refer  to  the  Ongoing  Implementation  Agreements) . 


Transport  Class  0 
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4.5.2.1  Transport  Class  0  Overview 

Transport  Class  0  over  X.25  is  mandatory  (see  X.400)  for  use 
in  communicating  with  public  MHS  systems  operating  in 
accordance  with  the  CCITT  X.400  series  recommendations.  The 
purpose  of  the  agreements  concerning  Transport  Class  0  is  to 
allow  connection  to  these  public  services.     Transport  Class 
0  over  X.25  can  also  be  used  in  communicating  between  PRMDs 
(this  choice  is  prevalent  outside  North  America). 

4.5.2.2  Protocol  Agreements 
Transport  Class  0  agreements  follow. 

o        The  Error  (ER)  TPDU  may  be  used  at  any  time  and  upon 
receipt  requires  that  the  recipient  disconnect  the 
network  connection,  and  by  extension  the  transport 
connection. 

o        The  allowed  values  for  the  maximum  TPDU  size  are  128, 
256,   512,   1024,  and  2048. 

o        The  Class  0  protocol  does  not  support  multiplexing.  At 
any  instant,  one  Transport  corresponds  to  one  Network 
connection. 

o  It  is  recommended  that  the  optional  timers  TSl  and  TS2 , 
if  implemented,  be  settable  by  local  system  management. 
Values  in  the  order  of  minutes  should  be  supported. 

o        An  unlimited  TSDU  length  must  be  supported. 

4.5.2.2.1  Transport  Class  0  Service  Access  Points 

For  communicating  with  public  MHS  systems,  section  5  of 
X.410  specifies  the  use  and  format  of  TSAP  identifiers. 

4.5.2.3  Rules  for  Negotiation 

The  rules  for  class  negotiation  shall  be  used. 
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4.5.3  Transport  Class  2 

4.5.3.1  Transport  Class  2  Overview 

Transport  Class  2  is  applicable  in  OSI  end  systems  which 
provide  the  Connection-mode  Network  Service. 

4.5.3.2  Protocol  Agreements 

Transport  Class  2  agreements  follow: 

The  values  of  the  TSl  and  TS2  timers  shall  be 
configurable.  The  recommended  timer  values  are: 

TSl :  60  seconds 
TS2 :  60  seconds 

If  present,   the  TSAP-id  field  in  the  CR  and  CC  TDPUs 
shall  be  encoded  as  a  variable  length  field  and  will  be 
interpreted  as  an  octet  string.     The  length  of  the 
string  cannot  exceed  32  octets 

The  rules  for  class  negotiation  shall  be  used. 

QoS  negotiation  is  outside  the  scope  of  these 
agreements.     If  QoS  negotiation  is  not  supported, 
receipt  of  the  parameters  "throughput,"   "residual  error 
rate,"   "priority,"  and  "transit  delay"  in  the  CR  and 
CC  TPDU  shall  be  ignored. 

Note  1:  If  Class  0  is  indicated  in  the  Alternative 
Protocol  Class  field  and  QoS  parameters  are 
conveyed  and  the  responding  end  system 
chooses  Class  0,  then  the  QoS  parameters  have 
been  ignored  by  the  responding  system. 

4.6     PROVISION  OF  CONNECTIONLESS  TRANSPORT  SERVICE 


Document  ISO      8072/Add.   2  is  the  Transport  Service  Definition 
covering  Connectionless-mode  Transmission.     Document     ISO  8602  is  the 
Protocol  for  providing  the  Connectionless -Mode  Transport  Service. 
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4.6.1  Connectionless  Transport  Overview 

When  providing  the  connectionless  Transport  Service,  the 
protocol  shall  be  implemented  as  specified  in    ISO  8602. 

4.6.2  Protocol  Agreements 

The  connectionless  Transport  protocol  is  a  relatively  simple 
protocol  providing  little  opportunity  for  conflicting 
interpretations.     A  few  relevant  agreements  follow. 

o        The  optional  elements  of  procedure  for  use  of  CLTS  over 
CONS  (i.e.,  clause  6.3  of    ISO  8602)  will  not  be 
supported. 

o        A  Unitdata  TPDU  that  is  received  that  contains  a 

protocol  error  or  an  unknown  destination  TSAP  ID  shall 
be  discarded. 


4  ■  6  ■  2  ■  1      Connectionless  Transport  Service  Access  Points  or 
Selectors 

The  TSAP  selector  field  in  the  UD  TPDU  shall  be  encoded  as  a 
variable  length  field  and  will  be  interpreted  as  an  octet 
string.     The  length  of  the  string  cannot  exceed  32  octets. 

4.7     TRANSPORT  PROTOCOL  IDENTIFICATION 


The  absence  of  Call  User  Data  (CUD)  in  an  X.25/ISO  8208  Call 
Request/Incoming  Call  packet  indicates  the  operation  of  ISO 
8073/CCITT  X.224. 

Protocol  Identification  TPDU  values  applicable  to  these  agreements  are 
given  in  table  4.1.  These  TPDUs ,  when  used,  are  conveyed  as  N-connect 
user  data. 
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Table  4.1.     Protocol  Identification  TPDU  Values 


TPDU  Value 

Protocol 

03     01     01     00  * 
03    01     02  00 

ISO  8073/Add.  1 
ISO  8602 

Notes:         *        Corresponds  to  an  ISO  8073/Add.    1  UN-TPDU 
and  a  X.224  Annex  B  PI -TPDU. 

Corresponds  to  an  ISO  8073/Add.   1  UN-TPDU 

The  following  agreements  apply. 

o        Any  additional  TPDU,  which  follows  (by  concatenation)  a 
Protocol  Identification  TPDU  shall  be  ignored  if  ISO 
8073/Add.   1  is  not  supported. 

o        When  using  ISO  8208,  usage  of  a  Protocol  Identification  TPDU 
not  corresponding  to  those  listed  in  table  4.1  is  outside 
the  scope  of  these  agreements . 
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5^  UPPER  LAYERS 


5.1  INTRODUCTION 

In  this  portion  of  the  Implementors '  Agreements,  the  NIST  Upper  Layers 
SIG  is  primarily  concerned  with  providing  implementation  agreements 
for  ACSE,  ROSE,  RTSE,  and  the  Presentation  and  Session  layers,  so  that 
systems  implemented  according  to  these  agreements  can  successfully 
interoperate . 

5.1.1  References 

All  documents  referenced  in  the  Upper  Layers  section  of  these 
agreements  can  be  found  in  the  REFERENCES  section  of  this  NIST 
Implementation  Agreements  document. 

5.2  SCOPE  AND  FIELD  OF  APPLICATION 


The  agreements  in  this  section  apply  to  all  ASE  agreements  in  this 
document.  Each  ASE  SIG  chooses  which  protocols,  functional  units, 
application  contexts,  and  parameters  it  requires.  These  must  be 
listed  in  the  "Specific  ASE  Requirements"  section  of  this  chapter. 

5.3  STATUS 

This  text  is  stable  as  of  December,  1989. 

5.4  ERRATA 

5.4.1  ISO  Defect  Solutions 

This  section  lists  the  defect  solutions  from  ISO  which  are 
currently  recognized  to  be  valid  for  the  purposes  of  NIST 
conformance : 

ISO  8326  defect  solutions: 

023,  024 
ISO  8327  defect  solutions: 

037,  038 
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5.4.2         Session   Defect    Solutions    Correcting    CCITT   X.215  and 
X.225 

The  following  approved  defect  solutions  have  been  integrated  into 
the  current  revisions  of  ISO  8326  and  ISO  8327,  but  are  not  part 
of  CCITT  X.215  and  X.225  (1984).  The  defect  solutions  must  be 
incorporated  into  CCITT  Session  to  insure  conformance  with  ISO 
Session. 

ISO  8326  defect  solutions: 

004,  006,  007,  009,  Oil,  012,  013,  014,  015,  016,  017,  020. 

ISO  8327  defect  solutions: 

001,  003,  004,  005,  006,  007,  008,  009,  010,  012,  017,  018, 
019,  026,  027,  030,  034,  035. 


5.4.3  Errata  approved  at  March.   1990  meeting 

Errata  to  this  chapter  are  marked  with  change  bars;  deleted  text 
is  left  but  with  strikeouts.  The  following  table  indicates  the 
section  and  type  for  each  erratum. 

COMMENT 


added  errata  summary  table 

grammar 

spelling 

typographical 

extraneous  word 

update  to  document  reference 

update  to  document  reference 

moved    some    abstract    syntaxes  so 

that     all     abstract     syntaxes  are 

listed  under  Presentation 

requirements;  deleted  some 

Associated  transfer  syntax  entries 

so  that  there  is  only  one  reference 

to  Associated   transfer   syntax  per 

group  of  abstract  sjmtaxes 

changes    to    the    encoding    of  two 

FTAM      abstract      syntaxes:  "NBS 

abstract  syntax  ASl"  and  "NBS  file 

directory  entry  abstract  syntax" 

correction      to      abstract  S3nitax 

definition 

added  explanatory  note  on  nil 
application  context 
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5.4.3  editorial 
5.5.2  editorial 
5.8.3.7  editorial 
5.8.5.1  editorial 
5.8.5.1  editorial 
5.8.7  editorial 

5.9.4  editorial 
5.12.1  editorial 


5.12.1.1.1  technical 

5.14.2  editorial 
5.14.2  editorial 
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5.5    ASSOCIATION  CONTROL  SERVICE  ELEMENT 


5.5.1  Introduction 

This  section  details  the  implementation  requirements  for  the 
Association  Control  Service  Element  (ACSE)  of  the  Application 
layer  as  defined  in  ISO  8649  and  ISO  8650. 


5.5.2  Services 

All  ACSE  services  are  within  the  possible  scope  of  a  NIST- 
conformant  system. 


5.5.3  Protocol  Agreements 


5.5.3.1      Application  Context 

Values  for  and  uses  of  Application  Context  names  are 
determined  by  specific  ASEs .  Values  used  by  NIST  ASE  SIGS 
are  listed  in  the  section  entitled  "Specific  ASE 
Requirements . " 


5.5.3.2      AE  Title 

AE- titles  shall  be  implemented  as  specified  in  Amendment  1 
to  ISO  8650  (ISO  8650/AM1). 


5.5.4  ASN.l  Encoding  Rules 

When  the  ABRT  APDU  is  used  during  the  connection  establishment 
phase,  Presentation  layer  negotiation  is  considered  to  be 
complete,  and  the  "direct-reference"  component  of  EXTERNAL  shall 
not  be  present. 

5.5.5  Connectionless 

The  connectionless  ACSE  protocol  shall  be  implemented  as 
specified  in  ISO  DIS  10035. 

No  further  agreements  beyond  those  specified  elsewhere  in  this 
chapter  have  been  made  regarding  this  standard. 
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Refer  to  Working  Implementation  Agreements,  March -199G7 
September  1990. 

5.6  ROSE 


ROSE  shall  be  implemented  as  specified  in  ISO  DIS  9072-1.2  and  ISO  DIS 
9072-2.2. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  chapter 
have  been  made  regarding  this  standard. 

5.7  RTSE 


RTSE  shall  be  implemented  as  specified  in  ISO  9066-1  and  ISO  9066-2. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  chapter 
have  been  made  regarding  this  standard. 

5.8  PRESENTATION 


5.8.1  Introduction 

This  section  details  the  implementation  requirements  for  the 
Presentation  layer  as  defined  in  the  Presentation  Service 
Definition,  ISO  8822,  and  the  Presentation  Protocol  Definition, 
ISO  8823. 

The  task  of  the  Presentation  layer  is  to  carry  out  the 
negotiation  of  transfer  syntaxes  and  to  provide  for  the 
transformation  to  and  from  transfer  syntaxes.  The  transformation 
to  and  from  a  particular  transfer  syntax  is  a  local 
implementation  issue  and  is  not  discussed  within  this  section. 
This  section  is  concerned  with  the  protocol  agreements,  and  thus 
is  entirely  devoted  to  the  issues  involved  with  the  negotiation 
of  transfer  syntaxes  and  the  responsibilities  of  the  Presentation 
protocol . 

5.8.2  Service 

Only  the  Kernel  functional  unit  need  be  supported.  The 
Context  Management  and  Context  Restoration  functional  units 
are  outside  the  scope  of  these  agreements. 
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The  requirement  that  the  Presentation  kernel  functional  unit 
be  implemented  does  not  imply  that  any  of  the  Session 
functional  units  for  expedited  data,  typed  data,  and 
capability  data  and  the  corresponding  Presentation  service 
primitives  are  required  to  be  implemented. 


5.8.3  Protocol  Agreements 


5.8.3.1      Transfer  Syntaxes 


The  following  transfer  syntax  must  be  supported 
for  all  mandatory  abstract  syntaxes:  the  basic 
encoding  rules  for  ASN.l.  This  syntax  is  derived 
by  applying  the  basic  encoding  rules  for  ASN.l  to 
the  abstract  syntax  (see  the  Basic  Encoding  Rules 
for  ASN.l,  ISO  8825). 

The  number  of  transfer  syntaxes  proposed  is 
dependent  upon  the  recognized  transfer  syntaxes 
which  are  available  to  support  the  particular 
abstract  syntaxes  used  by  an  Application  Entity. 


5.8.3.2      Presentation  Context  Identifier 

o  A  conformant  implementation  shall  encode 
Presentation  context  identifiers  in  the  range  0  to 
32,767. 

o  Implementations  must  be  able  to  handle  a  minimum 
of  two  Presentation  contexts  per  connection. 


5.8.3.3      Default  Context 

If  the  Presentation  expedited  data  service  is  required,  the 

default  context  must  be  explicitly  present  in  the  P-CONNECT 
PPDU  at  Presentation  connect  time. 


5.8.3.4  P-Selectors 

Local  P-selectors  shall  be  a  maximum  of  four  octets.  This 
applies  only  to  P-selectors  in  PPDUs  whose  receipt  by  an 
NIST-conformant  system  normally  results  in  either  a 
P-CONNECT  indication  or  a  P-CONNECT  confirmation  being 
issued. 
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5.8.3.5  Provider  Abort  Parameters 

No  conformance  requirements  are  implied  by  the  use  of  either 
the  Abort-reason  or  the  Event- identifier  component  of  the 
ARP-PPDU,  The  decision  to  include  these  parameters  is  left 
up  to  the  implementation  issuing  the  abort. 

5.8.3.6  Provider  Aborts  and  Session  Version 

The  Presentation  Provider  Abort  PPDU  (ARP-PPDU)  shall  be 
present  regardless  of  the  Session  version  in  effect  for  a 
given  association.  This  precludes  the  use  of  indefinite 
length  encoding  of  an  ARP-PPDU  when  Session  Version  1  is  in 
effect . 


5.8.3.7  CPC-Tvpe 

Implementations  shall  not  use  any  CPC-type  valvues  in  the 
SS-user  data  parameter  of  the  S-CONNECT  unless  more  than 
one  transfer  syntax  is  proposed  for  a  single  Presentation 
context  of  the  Presentation  data  values.  Each  CPC-type 
represents  a  unique  transfer  syntax,  so  if  more  than  one 
transfer  syntax  is  proposed,  CPC-type  values  may  appear  in 
that  SS-user-data  parameter. 

For  a  Presentation  context  for  which  the  Basic  Encoding 
Rules  are  a  proposed  transfer  syntax,  all  PDVs  in  the  user 
data  parameter  of  the  CP  PPDU  must  be  encoded  first  using 
the  Basic  Encoding  Rules  and  must  be  examined  by  the 
receiving  Presentation  protocol  machine.  Following  CPC-type 
values  may  be  examined  or  ignored  at  the  receiver's  option 
(see  ISO  8823,  sec.  6.2.5.3). 

5.8.3.8  Presentation-context-definition- result- list 

No  semantics  are  implied  by  the  absence  of  the  optional 
Presentation-context-definition-result- list  component  of  the 
CPR-PPDU,  This  component  is  required  if  the  Provider- reason 
is  absent  in  the  CPR-PPDU.  If  the  Provider-reason  is 
present,  then  the  Presentation-context-definition-result- 
list  is  optional. 
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The  Presentation-context- identifier- list  shall  not  be 
present  when  only  the  kernel  functional  unit  is  in  effect. 

5.8.4  Presentation  ASN.l  Encoding  Rules 

5.8.4.1       Invalid  Encoding 

If  a  received  PPDU  contains  any  improperly  encoded  data 
values  (including  data  values  embedded  within  the  User  Data 
field  of  a  PPDU)  and  an  abort  is  issued,  then  either  an  ARU 
or  an  ARP  shall  be  issued. 


5.8.5  General 


5.8.5.1      Presentation  Data  Value  (PDV) 

o  A  Presentation  data  value  (PDV)  is  a  value  of  a  type  in 
an  abstract  syntax,  e.g.,  a  value  of  an  ASN.l  type. 

o  A  PDV  may  contain  embedded  PDVs  in  different  contexts. 
A  change  of  context  within  a  PDV  is  indicated  by  an 
EXTERNAL.     EXTERNAL  implies  an  embedded  PDV. 

o  A  PDV  cannot  be  split  across  PDV- lists  in  fully-encoded 
user  data. 

o  Fully-encoded-data  that  is  a  series  of  PDVs  in  the  same 
Presentation  context  (e.g.,  grouped  FTAM  PDUs)  shall 
be  encoded  either  as  a  single  PDV- list  (using  the 
octet-aligned  choice)  or  as  a  series  of  PDV-lists,  each 
encoding  either  a  single  PDV  (using  the 
s ingle -ASNl- type  choice)  or  multiple  PDVs  (using  the 
octet-aligned  choice) .  Note  that  receivers  must  accept 
any  of  the  above  encodings. 

5.8.6  Connection  Oriented 

The  Transfer- syntax-name  component  of  a  PDV-list  value  shall  be 
present  in  a  CP  PPDU  if  and  only  if  more  than  one  transfer  syntax 
name  was  proposed  for  the  Presentation  context  of  the 
Presentation  data  values.  The  Transfer- syntax-name  component  of 
a  PDV-list  value  shall  always  be  present  in  a  CPC-type.  If  only 
the      Kernel      functional      unit      is      negotiated,       then  the 
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Transfer- syntax-name  component  of  a  PDV-list  value  shall  only 
appear  in  the  CP  PPDU  and  CPC-type. 

5.8.7  Connectionless 

The  connectionless  Presentation  protocol  shall  be  implemented  as 
specified  in  ISO  DIS  9576. 

The  Transfer- syntax-name  component  of  a  PDV-list  value  shall  be 
present  in  a  UD  PPDU  if  and  only  if  more  than  one  transfer 
syntax  name  was  proposed  for  the  Presentation  context  of  the 
Presentation  data  values.  The  Transfer- syntax-name  component  of 
a  PDV-list  value  shall  always  be  present  in  a  UDC-type.  The 
Transfer -syntax -name  component  of  a  PDV-list  value  shall  only 
appear  in  the  UD  PPDU  and  UDC-type. 

No  further  agreements  beyond  those  specified  elsewhere  in  this 
chapter  have  been  made  regarding  this  standard. 

SESSION 


5.9.1  Introduction 

This  section  details  the  implementation  requirements  for  the 
Session  layer  as  defined  in  the  Session  Service  Definition,  ISO 
8326  and  the  Session  Protocol  Definition,  ISO  8327. 


5.9.2  Services 

The  following  functional  units  are  within  the  scope  of  a  NISI 
conformant  system. 

Kernel 

Duplex 

Expedited  Data 
Resynchronize 
Exceptions 
Activity  Management 
Half -duplex 
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Minor  Synchronize 
Major  Synchronize 
Typed  Data 

5.9.3  Protocol  Agreements 

5.9.3.1  Concatenation 

When  a  category  0  SPDU  is  concatenated  with  a  category  2 
SPDU,  the  category  0  SPDU  shall  not  contain  User  Data. 

Extended  concatenation  is  not  required  and  can  be  refused 
using  the  normal  negotiation  mechanisms  of  the  Session 
protocol . 

5.9.3.2  Segmenting 

Session  segmenting  is  not  required  and  can  be  refused  using 
the  normal  negotiation  mechanisms  of  the  Session  protocol. 
All  conformant  implementations  shall  be  able  to  interwork 
without  Session  segmenting. 

5.9.3.3  Reuse  of  Transport  Connection 

Reuse  of  a  Transport  connection  is  not  required  and  can  be 
refused. 


5.9.3.4  Use  of  Transport  Expedited  Data 

The  Session  use  of  Transport  expedited  service  is  supported. 
The  meaning  of  "supported"  is  specified  in  section  3.1  of 
ISO  DISP  AFTnn-1. 

Note:  It  is  recommended  to  request  and  use  this  feature. 

5.9.3.5  Use  of  Session  Version  Number 

Session  Versions  1  and  2  are  recognized.  Each  relevant 
NIST  SIG  chooses  the  version  or  versions  of  Session  which  it 
requires  for  a  particular  implementation  phase,  and  these 
choices  are  documented  in  section  5.12. 
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Session  Version  2  specifies  the  use  of  unlimited  user  data 
during  connection  establishment  as  dictated  by  the  AD  2  to 
ISO  8327  to  Incorporate  Unlimited  User  Data, 

All  Session  Version  1  implementations  must  be  able  to 
negotiate  Version  1  operation  when  responding  to  a  CONNECT 
(CN)  SPDU  proposing  both  Version  1  and  Version  2. 

In  addition,  all  Session  Version  1  implementations,  upon 
receipt  of  a  CONNECT  (CN)  SPDU  proposing  only  Version  2, 
should  respond  with  a  REFUSE  (RF)  SPDU  containing  a  Reason 
Code  indicating  that  the  proposed  version  is  not  supported. 
Until  pending  defect  reports  are  adopted,  implementations 
may  disconnect. 

If  Session  Versions  1  and  2  are  both  proposed  in  the 
CONNECT  (CN)  SPDU,  then  the  maximum  length  of  the  User  Data 
parameter  value  in  the  CONNECT  (CN)  SPDU  shall  be  512  octets 
and  a  PGI  field  of  193  shall  be  associated  with  this 
parameter.  This  implies  that  an  implementation  supporting 
both  Session  Versions  1  and  2  can  establish  a  connection 
with  an  implementation  supporting  only  Version  1. 

If  only  Session  Version  2  is  proposed  in  the  CONNECT  (CN) 
SPDU,  then  the  maximum  length  of  the  Session  User  Data 
parameter  value  of  the  S-CONNECT  service  request  shall  be 
10,240  octets.  This  restriction  implies  that  the  OVERFLOW 
ACCEPT  (OA)  SPDU  and  CONNECT  DATA  OVERFLOW  (CDO)  SPDU  are 
not  used.  If  the  length  of  the  User  Data  parameter  value  is 
no  greater  than  512  octets,  then  an  associated  PGI  field  of 
193  shall  be  used,  otherwise  a  PGI  field  of  194  shall  be 
used. 

When  Session  Version  2  is  negotiated,  then  in  all  SPDUs  the 
maximum  length  of  the  User  Data  parameter  value  with  an 
associated  PGI  field  of  193  shall  be  10,240  octets.  NIST- 
conformant  Session  Version  2  implementations  need  only 
support  the  maximum  data  lengths  specified  in  the  Specific 
ASE  Requirements  section. 

5.9.3.6      Receipt  of  Invalid  SPDUs 

Upon  receipt  of  an  invalid  SPDU,  the  SPM  shall  take  any 
action  in  A. 4. 3  of  the  Session  Protocol  Definition  ISO/IS 
8327  except  Action  d. 
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5.9.3.7      Invalid  SPM  Intersections 

If  the  conditions  described  in  A. 4. 1.2  of  the  Session 
Protocol  Definition  ISO/IS  8327  are  satisfied,  the  SPM  shall 
always  take  the  actions  described  by  A. 4. 1.2  a. 

Note:  This       implies       that      no       S-P- EXCEPTION -REPORT 

indications  will  be  generated  nor  EXCEPTION 
REPORT  SPDUs  sent  due  to  invalid  intersections  of 
the  Session  state  table  resulting  from  received 
SPDUs . 


5.9.3.8  S-Selectors 

S-selectors  shall  be  a  maximum  of  16  octets. 


5.9.4  Connectionless 

The  connectionless  Session  protocol  shall  be  implemented  as 
specified  in  ISO  IS  9548. 

No  further  agreements  beyond  those  specified  elsewhere  in  this 
chapter  have  been  made  regarding  this  standard. 

10  UNIVERSAL  ASN . 1  ENCODING  RULES 


5. 10. 1  TAGS 

The  maximum  value  of  an  ASN.l  basic  encoding  tag  that  need  be 
handled  by  an  NIST-conformant  implementation  shall  be  16,383. 
This  is  the  maximum  unsigned  number  that  can  be  represented  in  14 
bits,  therefore,  the  maximum  encoding  of  a  tag  occupies  3  octets. 

5.10.2  Definite  Length 

The  maximum  value  of  an  ASN.l  length  octets  component  that  need 
be  handled  by  an  NIST-conformant  implementation  shall  be 
4,294,967,295.  This  is  the  maximum  unsigned  integer  that  can  be 
represented  in  32  bits,  therefore,  the  maximum  encoding  of  a 
length  octets  component  will  occupy  5  octets.  Also,  note  this 
restriction  does  not  apply  to  indefinite  length  encoding. 
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It  is  assumed  that  "Presentation  layer  negotiation  of  encoding 
rules"  is  always  in  effect,  and  therefore  clause  32.5  of  the 
Specification  of  ASN.l,  ISO  8824  never  applies. 

a.  If  a  data  value  to  be  encapsulated  in  an  EXTERNAL  type  is 
an  instance  of  a  single  ASN.l  type  encoded  according  to  the 
Basic  Encoding  Rules  for  ASN.l,  then  the  option 
" s ingle - ASN. 1- type"  shall  be  chosen  as  its  encoding. 

b .  If  a  data  value  to  be  encapsulated  in  an  EXTERNAL  type  is 
encoded  as  an  integral  number  of  octets,  and  case  a.  does 
not  apply,  then  the  option  "octet-aligned"  shall  be  chosen 
as  its  encoding. 


5 . 10.4  Integer 

o  Any  incidence  of  an  ASN.l  INTEGER  type  defined  in  an 
abstract  syntax  describing  protocol  control  information 
must  be  encoded  so  that  the  length  of  its  contents  octets  is 
no  more  than  four  octets,  unless  an  explicit  NIST  agreement 
to  the  contrary  is  made  for  a  specific  INTEGER  type. 


5. 10.5        String  Types 

o    '    The    contents    octets    for    a    constructed   encoding   of   a  BIT 
.       STRING,   OCTET  STRING,   or  character  string  value  consists  of 
the  complete  encoding  of  zero,  one,  or  more  data  values,  and 
the  encoding  of  these  data  values  must  be  primitive. 


5 . 10. 6        Bit  String 

o  Unless  otherwise  specified  in  the  abstract  syntax 
definition,  each  bit  named  in  a  BIT  STRING  type  used  in  that 
abstract  syntax  definition  shall  be  explicitly  encoded  in 
the  associated  BIT  STRING  value,  even  if  it  is  part  of  a 
string  of  trailing  zero  bits. 

Extra  trailing  bits  beyond  the  exact  number  of  bits  which 
correspond  to  the  complete  list  of  the  named  bits  specified 
shall  never  be  encoded.  This  rule  applies  to  all  BIT  STRING 
types  unless  stated  otherwise  in  the  standards. 
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See  aligned  section  of  Working  Implementation  Agreements  dated 
December  1989. 


5.12  CONFORMANCE 

In  order  for  an  implementation  to  be  in  conformance  with  the  NIST 
implementors '  agreements,  the  rules  below  shall  be  followed. 

o  A  conformant  implementation  must  meet  all  of  the  requirements  of 
this  specification.  All  documents  referenced  in  the  Upper  Layers 
section  shall  be  used  as  the  supporting  documents  for  all 
implementations  of  ACSE,  ROSE,  RTSE,  Presentation,  or  Session. 
The  full  references  for  these  documents  are  in  the  REFERENCES 
section. 

o  NIST-conformant  implementations  shall  be  ISO  conformant.  PICS 
may  contain  limitations  on  length  or  value  aspects  of  a  protocol. 
PICS  of  NIST-conformant  systems  shall  not  contain  restrictions 
more  severe  than  those  in  these  implementation  agreements. 


The  following  list  for  each  ASE  the  corresponding    NIST  SIG's 
requirements  of  and  restrictions  on  ACSE,  ROSE,  RTSE, 
Presentation,  and  Session. 

All  listed  requirements  and  restrictions  shall  be  included  in  an 
NIST-conformant  system  and  shall  be  implemented  in  accordance 
with  these    NIST  Implementor ' s  agreements. 


Note: 


An  implementation  may  abort  a  connection  if  the 
constraints  specified  in  these  agreements  are 
violated. 


5.12.1 


Specific  ASE  Requirements 


5.12.1.1  FTAM 


5.12.1.1.1 


Phase  2 


ACSE  Requirements: 
all 


Application  Contexts: 


o        "ISO  FTAM 
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{  iso(l)  standard(O)  8571 
application-context  iso-ftam(l)  } 
-  implies  the  use  of  the  ACSE  and  the 
FTAM  ASE. 

A  -value  -is  -defined  -for  -the  -AE  -Title  -only  -te 
satisfy -the -FTAM -requirement -for -exchanging -fields 
of  -this -typeT 

This -value -does -not -identify -an -Application -Entity 
and  -carries  -no  -semantics -  -The  -AE  -title  -maps  -onto 
the  -AP  -title  -and  -the  -AE  -qualifier .-  -  -If  -the  -AE 
title  -is  -used ,-  -then  -both  -AP  -title  -  (^an  -GBJEGT 
IDENTIFIER>  -and  -AE  -qualifier  -  (-an  -INTEGER>  -must  -be 
sentr 

The -value -for -the -AP -title -is -f  -1 -S - -9999  -1 
f  tam-nil-ap-title  -f?}     -at  -this  -time .-  -  -Values  -for 
the  -AE  -qualifier -are -outside -the -scope -of -these 
agreements 7 

A  value  is  defined  for  the  AE  Title  only  to 
satisfy  the  FTAM  requirement  for  exchanging  fields 
of  this  type.     This  value  does  not  identify  an 
Application  Entity  and  carries  no  semantics. 

If  the  AE  title  is  used,  AE- title- form2  shall  be 
supported.     Support  of  AE- title-form2  includes 
support  of  AP- title-form2  and  AE-qualif ier-form2 . 

The  value  for  the  AP  title  is  {  1  3    9999  1 
f tam-nil-ap-title  (7)   }  at  this  time.     Values  for 
the  AE  qualifier  are  outside  the  scope  of  these 
agreements . 

The  use  of  AP  invocation  identifiers  and  AE 
invocation  identifiers  by  FTAM  is  outside  the 
scope  of  these  agreements . 


Presentation  Requirements: 

Presentation  Functional  Units: 
o  kernel 

Presentation  Contexts: 

o        At  least  3  Presentation  Contexts  must  be 
supported. 
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{ joint-iso-ccitt(2) 
association-control (2) 

abstract- S3mtax(l)  apdus(O)  versionl(l) 
) 

o  "FTAM-PCI" 

{  iso(l)  standard(O)  8571 
abstract "Syntax( 2)  ftani-pci(l)  } 

Asseei-afced  -Transfer  -Syi^feaxt 
o        '^Basie  -Encoding  -of  -a  -single  -ASK  rl 
type" 

t-  -j-oinc-i90-eeifct(-2>  -asnlr(-lr) 
basie-eneodingfl)-  -) 

o        "FTAM  unstructured  binary  abstract 
syntax" 

{  iso(l)  standard(O)  8571 
abstract-syntax(2) 
unstructured-binary(4)  ) 

-Assoeiafeed -Transfer -Syntaxf 
o        '^Basie  -Encoding  -of  -a  -singTbe  -ASN  .-1 
t3^e« 

f  -j-oinfe-iso-eeitfe(-2)--asnlf]r) 
basic -encoding -) 

Editor's  Note:  In    Definitions    below,  "NBS" 
designation  will  be  preserved. 

Abstract  Syntaxes  Depending  on 
Implementation  Profile 

o  "FTAM-FADU" 

{  iso(l)  standard(O)  abstract-s3mtax(2) 
ftain-fadu(2)  ) 

Asaoeiafeed  -Transf  eif  -Syntax  f 
o        '^Basie  -Encoding  -of  -a  -single  -ASN  .-1 
type" 

i-  -j-oinfc-tso-eeittf2>-a3n]r(-t) 
basic -encoding  (-!:> 

o        "FTAM  unstructured  text  abstract  S3mtax" 
{  iso(l)  standard(O)  8571 
abstract- syntaxC 2)  unstructured- text (3) 
} 

Associated -Transfer -Syntaxt 
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o        '^Basie  -Encoding  -of  -a  -single  -ASN  .-1 
feype" 

t  -j-oint-i90-eeifetf2> -asntf t) 
baste-eneodtngf 

o        "NBS  abstract  syntax  ASl" 

{  iso  identif ied-organization  oiw(14) 
ftanisig(5)  abstract-syntax(2)  nbs-asl(l) 
} 

Assoeiafeed -Ttansf -Syntax t 
o        '^Basie  -Encoding  -  -of  -a  -single  -ASN  .-1 
type" 

{-  -j-©tnfe-is©-eeifetf  2>  -asntf  1) 
basic -encoding  (•!)■  -) 

o        "NBS  file  directory  entry  abstract 
syntax" 

{  iso  identif ied-organization  oiw(14) 
ftamsig(5)  abstract-syntax(2)  nbs-as2(2) 
} 


Associated  Transfer  S3mtax: 

o        "Basic  Encoding  of  a  single  ASN.l 
type" 

{  joint-isc-ccitt(2)  asnl(l) 
basic-encoding(l)  ) 

Editor's  Note:  The  changes  above  involving  "0IW(14)"  were 
not  explicitly  mentioned  at  the  March  1990 
Plenary,  but  were  implied  from  a 
correspondingly  approved  FTAM  motion. 


Session  Requirements: 

Session  Functional  Units: 

o  kernel 

o  duplex 
¥ersion  Nussber:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 

Session  Options: 

Session  Functional  Units: 
o  resynchronize 

only  a  Resjmchronize  Type  value  of 
"abandon" 
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o        minor  synchronize 

Note:  The  minor  synchronize 

functional  unit  is 
required  whenever  the 
resynchronize  functional 
unit  is  available. 

The  default  value  for  Minor  Sync  Point  Sync 
type  item  shall  always  be  used,  i.e., 
explicit  confirmation  is  required. 

ASN.l  Encoding  Requirements 

Some  INTEGER  types  of  the  FTAM  PCI  may  exceed  the 
maximum  size  specified  in  the  UNIVERSAL  ASN.l 
ENCODING  Rules.     See  the  Range  of  values  for 
INTEGER  type  Parameters  of  the  FTAM  chapter. 


5.12.1.2  MHS 


5.12.1.2.1  Phase  1  (1984  X.400) 

Session  Requirements: 

Session  Functional  Units: 
o  kernel 
o  half-duplex 
o  exceptions 
o        activity  management 
o        minor  synchronize 

Version  Number:  1 

Maximum  size  of  User  Data  parameter  field:  512 

Session  Notes: 

o        Restricted  use  is  made  by  the  RTS  of  the 
Session  services  implied  by  the 
functional  units  selected. 
Specifically, 

No  use  is  made  of  S-TOKEN-GIVE , 
and 

S- PLEASE -TOKENS  only  asks  for  the 
data  token. 
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o        In  the  S -CONNECT  SPDU,  the  Initial 

Serial  Number  should  not  be  present. 

o       The  format  of  the  Connection  Identifier 
in  the  S -CONNECT  SPDU  is  described  in 
Version  5  of  the  X.400-Series 
Implementors '  Guide. 


5.12.1.2.2  Phase  2.  Protocol  Pi  (1988  X.400) 

ROSE  Requirements; 

ROSE  is  not  used. 

RTSE  Requirements: 
o  Monologue 

o        TWA  -  optional 

o  checkpointing 

.minimum  checkpoints ize  =  1 

.minimum  windows ize  =  1 
,      o        no  checkpointing 

Notes : 

o        Monologue  Association: 

initiator  keeps  initial  turn 

APDUs  are  transferred  from 

initiator  to  responder  only 

no  turn  passing 

only  the  initiator  effects  the 

orderly  release  of  an  association 

o        Two  way  alternate  Association 

the  initiator  may  keep  or  pass  the 
initial  turn,  at  binding 
APDUs  are  transferred  by  the  holder 
of  the  turn 

only  the  initiator  effects  the 
orderly  release  of  an  association, 
when  it  possesses  the  turn 


ACSE  Requirements: 

As  per  Phase  2,  Protocol  P7 . 

Application  Contexts: 

o        "MTS-transfer-protocol-1984"  -  mandatory 

o        "MTS-transfer-protocol"  -  mandatory 

o        "MTS- transfer"  -  mandatory 
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Presentation  Requirements: 

Presentation  Functional  Units: 
o  kernel 

Presentation  Contexts: 

o        at  least  3  must  be  supported 

Abstract  Syntaxes: 

o        "ISO  8650-ACSEl" 

{ joint-iso-ccitt (2)  association-control (2) 
abstract-syntax(l)  apdus(O)  versionl(l)  } 

o  "MTS-RTSE" 

o  "MTSE" 

Associated  Transfer  Syntax: 

o        "Basic  Encoding  of  a  single  ASN.l 
type" 

[  joint-iso-ccitt(2)  asnl(l) 
basic-encoding(l)  ) 

Session  Requirements: 

As  per  Phase  2 ,  Protocol  P7 . 

5.12.1.2.3         Phase  2.  Protocol  P7  (1988  X.400) 

ROSE  Requirements: 

Operation  and  association  classes  are  used  as  per 
the  standard. 

RTSE  Requirements: 
o  TWA 
o        normal -mode 
o  checkpointing 

.minimum  checkpoints ize  =  1 

.minimum  windows ize  =  1 
o        no  checkpointing 

Notes : 

o        Monologue  Association: 

initiator  keeps  initial  turn 

APDUs  are  transferred  from 

initiator  to  responder  only 

no  turn  passing 

only  the  initiator  effects  the 

orderly  release  of  an  association 
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o       Two  way  alternate  Association 

the  initiator  may  keep  or  pass  the 
initial  turn,  at  binding 
APDUs  are  transferred  by  the  holder 
of  the  turn 

only  the  initiator  effects  the 
orderly  release  of  an  association, 
when  it  possesses  the  turn 

ACSE  Requirements : 
all 

The  use  of  AP-TITLE,  AE-QUALIFIER, 
AP- INVOCATION- ID,  and  AE-INVOCATION-ID    is  not 
recommended;  however,  a  receiving  entity  must  be 
capable  of  ignoring  them  (if  present)  without 
refusing  the  connection. 

Application  Contexts: 

o        "MS-access"  -  mandatory;  normal  mode 
o        "MS-reiiable-access"  -  optional;  normal 
mode 

Absferaet -Syntaxes t 

o  '^IS0-863G-AGSEt" 

f -j-otnt-i:so-eeitfe(-2) 
assoeiat ion-eontrol f 2) 

abstract-syntax  flr>  -apdusfO)-  -versiontf  1) 

:  y 

Associated -Transfer -Syntaxf 

o        -'^Baste  -Encoding  -of  -a  -single  -ASN  .-1 
type" 

{- -j-oint-iso-ceitt(^2> -asntft) 
basic-encoding  (-t)- -) 

Presentation  Requirements: 

Presentation  Functional  Units: 
o  kernel 

Presentation  Contexts: 
o        at  least  5 

Abstract  Syntaxes: 

o        "ISO  8650-ACSEl" 

{  joint-iso-ccitt(2) 
association-control (2) 

abstract-syntax( 1 )  apdus(O)  versionl(l) 
) 
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o  MSBind/MSUnbind  (with  or  without  RISE) 

o  MSSE  (Message  Submission) 

o  MASK  (Message  Administration) 

o  MRSE  (Message  Retrieval) 

Associated  Transfer  Syntax: 

o        "Basic  Encoding  of  a  single  ASN.l 
type" 

{  joint-iso~ccitt(2)  asnl(l) 
basic-encoding(l)  ) 

Session  Requirements: 

Session  Functional  Units: 
o  kernel 
o  half-duplex 
o  exceptions 
o        activity  management 
o        minor  synchronize 

Version  Nusoiber:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 

Session  Notes: 

o        MHS  proposes  both  versions  1  and  2  for 

pass  through  mode  (X.410  mode),  but  only 

version  2  for  normal  mode, 
o        Restricted  use  is  made  by  the  RTS  of  the 

Session  services  implied  by  the 

functional  units  selected. 

Specifically, 

No  use  is  made  of  S-TOKEN-GIVE, 
and 

S- PLEASE -TOKENS  only  asks  for  the 
data  token. 

o        In  the  S -CONNECT  SPDU,  the  Initial 

Serial  Number  should  not  be  present. 

o        The  format  of  the  Connection  Identifier 
in  the  S-CONNECT  SPDU  is  described  in 
Version  5  of  the  X.400-Series 
Implementors '  Guide. 
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5.12.1.2.4  Phase  2.  Protocol  P3  (1988  X.400) 

ROSE  Requirements: 

As  per  Phase  2,  P7. 

RTSE  Requirements: 

As  per  Phase  2 ,  P7 . 

4CSE_Jle£ulremepJ^l 

As  per  Phase  2,  P7 . 

Application  Contexts : 

o        "MTS- access"  -  mandatory 

o        "MTS-reliable-access"     -  optional 

o        "MTS-forced-access"        -  mandatory 

o        "MTS-forced- reliable-access"  -  optional 

Presentation  Requirements: 
As  per  Phase  2 ,  P7 . 

Session  Requirements: 

As  per  Phase  2,  P7. 


5.12.1.3  DS 


5.12.1,1,1  Phase..! 

ACSE  Requirements: 
all 

Application  Contexts: 

o  "id-ac-directoryAccessAC" 

{  joint-lsO"Ccitt(2)  ds(5)  3  1  } 

o  "id-ac-directorySy,3ten)AC" 

{  joint-i£o-ccitt(2)  ds(5)  3  2  ) 

Absfcraet -Syntaxes f 

o  'ilSG-S&SO-AGSEl" 

f- -j-otnfe-is©-eei:tfe(-2) 
assoeiation  -  control:  (-2) 

abstraec -syntax  (^lr>  -apdu3(-G>  -version!  6^) 
> 

Associated  -Tx^aBsf  er  -Syntax;  t 
0        '^Basi-e  -Bn^odtRg  -©f  -a  -single  -ASN  .-1 
type" 
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{--j-oinfe-iso-eeitfef2>  -asnlf  t) 
basie-eneodingf 1> -) 

o  '^id-as-direefeoryAeeessAS" 

j-otnfe-iso-eettfe62>  -d»65>  -9  -t  -) 

Associated -Transfer  -Syntaxf 

o        '^Basic -Encoding -of -a -single 
ASN.-t-feype" 

f  -j-oinfe-iso-ceitfef  2>  -asntf  t) 
basic -encoding  (■!:)■ 

o  '"^id-as-direefeorySysteiaAS" 

{-  -j-oinfe-iso-ccitt  f  2>  -dsf  5>  -9  -2  -) 

Associated -Transfer  -Synfeaxt 
o        '^Basic  -Encoding  -of  -a  -single  -ASN  .-1 
type" 

(-  -j-oint-iso-eeittf  2)-  -asntft) 
basic -encoding  (•!:>  -} 

Presentation  Requirements: 

Presentation  Functional  Units: 
o  kernel 

Presentation  Contexts: 

o        At  least  2  Presentation  Contexts  must  be 
supported. 

Abstract  Syntaxes: 

o        "ISO  8650-ACSEl" 

{  joint-iso-ccitt(2) 
association-control(2) 

abstract- s)mtax(l)  apdus(O)  versionl(l) 
) 

o  "id-as-directoryAccessAS" 

joint-iso-ccitt(2)  ds(5)  9  1  ) 

o  "id-as-directorySystemAS" 

{  joint-iso-ccitt(2)  ds(5)  9  2  ) 

Associated  Transfer  Syntax: 

o        "Basic  Encoding  of  a  single 
ASN.l  type" 

{  joint-iso-ccitt(2)  asnl(l) 
basic -encoding(l)  ) 

Session  Requirements: 
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Session  Functional  Units: 
o  kernel 
o  duplex 

Version  Number:  2 

Maximuni  size  of  User  Data  parameter  field: 
10,240 


5.12.1.4    Virtual  Terminal 


5.12.1.4.1  Phase  la 

ACSE  Requirements: 
all 

Application  Contexts: 
o        "ISO  VT" 

{  iso(l)  standard(O)  9041 

application-context(l)  } 

-  implies  the  use  of  the  ACSE  and  the  VT  ASK 

Abstract -Syntaxes t 

o  '^ISG-SSSG-AGSEt" 

f  -j-oinfe-iso-eeittf2)-  -a3soeiation-eontrolr(-2) 
absfe]faefe-synfeax(-lr> -apdus(-0> -versiont^^t)- 

Associated -Transfer -Syntaxt 

o        -'^Basie  -Encoding  -of  -a  -single  -ASN  .-1  -type" 
{-  -joint-iso-eeitt(-2>  -asnlf  t) 
basic-encoding  (•]:> 

Presentation  Requirements: 

Presentation  Functional  Units: 
o  kernel 

Presentation  Contexts: 

o        at  least  2  must  be  supported 

Abstract  Syntaxes: 

o        "ISO  8650-ACSEl" 

{  joint~iso-ccitt(2)  association-control(2) 
abs tract- syntax( 1 )  apdus(O)  versionl(l)  } 

o        "VT  Basic" 

{  iso(l)  standard(O)  9041  abstract-syntax(2) 
) 
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Associated  Transfer  Syntax: 

o        "Basic  Encoding  of  a  single  ASN.l  type" 
{  joint-iso-ccitt(2)  asnl(l) 
basic-encoding(l)  } 

Session  Requirements: 

Session  Functional  Units: 
o  kernel 
o  duplex 
o         expedited  data 
o         major  synchronize 
o  resynchronize 

-  only  a  Resjmchronize  Type  value  of 

"restart" 
o  typed  data 

Version  Number:  2 

Maxintum  size  of  User  Data  parameter  field:  10,240 

Session  Options: 

o         expedited  data 


5.12.1.4.2  Phase  lb 

ACSE  Requirements: 
all 

Application  Contexts: 
o        "ISO  VT" 

{  iso(l)  standard(O)  9041 
application-context (1)  ) 
-  implies  the  use  of  the  ACSE  and  the 
VT  ASE 


Presentation  Requirements: 

Presentation  Functional  Units: 
o  kernel 

Presentation  Contexts : 

o        at  least  2  must  be  supported 

Abstract  Syntaxes: 

o        "ISO  8650-ACSEl" 

{  joint-iso-ccitt(2) 
assoclation-control(2) 
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abstract-syntax(l)  apdus(O)  versionl(l) 
) 

o        "VT  Basic" 

{  iso(l)  standard(O)  9041 
abstract-syntax(2)  ) 

Associated  Transfer  Syntax: 

o        "Basic  Encoding  of  a  single  ASN.l 
type" 

(  joint-iso-ccitt(2)  asnl(l) 
basic-encoding(l)  } 

Session  Requirements: 

Session  Functional  Units: 
o  kernel 
o  duplex 
o  half-duplex 
o  expedited  data 

o         major  synchronize 
o  resynchronize 

-  only  a  Resynchronize  Type  value  of 

"restart" 
o         typed  data 

Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 

Session  Options: 

o         expedited  data 

5.12.1.5  MMS 

See  Working  Implementation  Agreements  Document,  March -1:9907 
September  1990. 
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5.12.1.6    Transaction  Processing 

See  Working  Implementation  Agreements  Document,  March -199Gt 
September  1990. 
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5.13  APPENDIX  A:     RECOMMENDED  PRACTICES 

The  optional  "Reflect  Parameter  Values"  parameter  in  the  Provider 
ABORT  SPDU  shall  be  encoded  so  as  to  represent  the  Session  connection 
state,  the  incoming  event  and  the  first  invalid  SPDU  field  exactly  at 
the  moment  a  protocol  error  was  detected. 

The  first  octet  encodes  the  Session  state  as  a  number  relative  to  0  as 
detailed  in  table  5.1. 

The  second  octet  encodes  the  incoming  event  as  a  number  relative  to  0 
as  detailed  in  table  5.2. 

The  third  octet  contains  the  SI,  PGI ,  or  PI  Code  of  any  SI  field,  PGI 
unit  or  PI  unit  in  error. 

Note:    The  remaining  6  octets  are  undefined  herein. 
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Table  5.1.  Session  States 

State      Rel .#  Description 

1  0  Idle,  no  transport  connection 

IB  1  Wait  for  T-connect  confirm 

IC  2  Idle,   transport  connected 

2A  3  Wait  for  the  ACCEPT  SPDU 

3  4  Wait  for  the  DISCONNECT  SPDU 

8  5  Wait  for  the  S-CONNECT  response 

9  6  Wait  for  the  S -RELEASE  response 

16  7  Wait  for  the  T-DISCONNECT  indication 

713  8  Data  Transfer  state 

lA  9  Wait  for  the  ABORT  ACCEPT  SPDU 

4A        10  Wait  for  the  MAJOR  SYNC  ACK  SPDU  or  PREPARE 

SPDU 

4B        11  Wait  for  the  ACTIVITY  END  ACK  SPDU  or  PREPARE 

SPDU 

5A        12  Wait  for  the  RESYNCHRONIZE  ACK  SPDU  or  PREPARE 

SPDU 

5B        13  Wait  for  the  ACTIVITY  INTERRUPT  SPDU  or  PREPARE 

SPDU 

5C        14  Wait  for  the  ACTIVITY  DISCARD  ACK  SPDU  or 

PREPARE 
SPDU 

6  15  Wait  for  the  RESYNCHRONIZE  SPDU  or  PREPARE 

SPDU 

lOA        16  Wait  for  the  S-SYNC-MAJOR  response 

lOB        17  Wait  for  the  S -ACTIVITY- END  response 

llA        18  Wait  for  the  S -RESYNCHRONIZE  response 

IIB        19  Wait  for  the  S-ACTIVirf- INTERRUPT  response 

lie        20  Wait  for  the  S-ACTIVITY-DISCARD  response 

15A        21  After  PREPARE,  wait  for  the  MAJOR  SYNC  ACK  SPDU  or  the 

ACTIVITY  END  ACK 

15B        22  After  PREPARE,  wait  for  the  RESYNCHRONIZE  SPDU  or  the 

ACTIVITY  DISCARD  SPDU 
15C        23  After  PREPARE,  wait  for  the  RESYNCHRONIZE  ACK  SPDU,  or 

the  ACTIVITY  INTERRUPT  ACK  SPDU  or  the  ACTIVITY  DISCARD 
ACK  SPDU 

18  24  Wait  for  GIVE  TOKENS  ACK  SPDU 

19  25  Wait  for  a  recovery  request  or  SPDU 

20  26  Wait  for  a  recovery  SPDU  or  request 

21  27  Wait  for  the  CAPABILITY  DATA  ACK  SPDU 

22  28  Wait  for  the  S- CAPABILITY- DATA  response 
ID  29  Wait  for  the  CONI^fECT  DATA  OVERFLOW  SPDU 
2B        30  Wait  for  the  OVERFLOW  ACCEPT  SPDU 

15D        31  After  PREPARE,  wait  for  the  ABORT  SPDU 
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Table  5.2.  Incoming  Events 


Ke  i .  w 

Description 

SCONreq 

0 

S- CONNECT  request 

SCONrsp+ 

1 

S -CONNECT  accept  response 

SCONrsp- 

z 

S -CONNECT  reject  response 

SDTreq 

3 

S-DATA  request 

SRELreq 

4 

S -RELEASE  request 

SRELrsp+ 

5 

S -RELEASE  accept  response 

SUABreq 

6 

S-U- ABORT  request 

TCONcnf 

7 

T-CONNECT  confirmation 

TCONind 

8 

T-CONNECT  indication 

TDISind 

9 

T-DISCONNECT  indication 

TIM 

10 

Time  out 

A  A 

AA 

i  i 

A  t>  /"XD  T     A          TT  T)*T' 

AJiUKi  ACUhr i 

AB-nr 

12 

ABORT  -  no  reuse 

AO 

ALUhr i 

CN 

1  A 

CONNECT 

DN 

15 

DISCONNECT 

DT 

16 

DATA  TRANSFER 

FN-nr 

1  / 

FINISH  -  no  reuse 

RF-nr 

18 

REFUSE  -  no  reuse 

SACTDreq 

19 

S -ACTIVITY- DISCARD  request 

SACTDrsp 

20 

S -ACTIVITY- DISCARD  response 

bAL  i  iLreq 

0  1 

b-ALiiVii  i-hlNU  request 

bAuifcrsp 

0  0 

b-ALiiiViii-E-JNU  response 

C  A  CTl fan 

bAui  ireq 

0  1 
Z  J 

b - AOi  1 V i i  1  - iJN i liKKUr i  request 

C  A  r"TT  vr^»^ 

Z4 

b-AOiiVii I -iJNitKKuri  response 

bAOiKreq 

Z  J 

b-ACiiVii i-KhbUMh.  request 

O  A  ^T^C  UAH 

bAOibreq 

Zo 

b-ACiiVii Y-biAKi  request 

O       T\       _  _ 

bODreq 

z  / 

b-CAFAliiLiii-DAiA  request 

bt/Ursp 

Zo 

b-CArAciLii i-UAiA  response 

SCGreq 

zy 

S- CON IROL- GIVE  request 

bhXreq 

o -EArciDi  ILD-DAiA  request 

SGTreq 

il 

S -TOKEN -GIVE  request 

br ireq 

JZ 

b- 1 OKLN - r LKAd h  request 

bKhLrsp- 

b-KhLhiAbb  response  reject 

bKb iNreq (a; 

j4 

b -REbYNCnRONlZh  request  aDanaon 

bKb  iJNreq  ) 

"3  1^ 
J  J 

b-Ktib iNCriKUiNiZh.  request  restart 

SRSYNreq(s) 

36 

S-RESYNCHRONIZE  request  set 

SRSYNrsp 

37 

S-RESYNCHRONIZE  response 

SSYNMreq 

38 

S-SYNC-MAJOR  request 

SSYNMrsp 

39 

S- SYNC -MAJOR  response 

SSYNmreq 

40 

S- SYNC -MINOR  request 

SSYNmrsp 

41 

S- SYNC -MINOR  response 

STDreq 

42 

S-TYPED-DATA  request 

SUERreq 

43 

S-U-EXCEPTION-REPORT  request 
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Table  5.2.  Incoming  Events  Continued 

Event  Rel .#  Description 

AB-r  44  ABORT  -  reuse  SPDU 

AD  45  ACTIVITY  DISCARD  SPDU 

ADA  46  ACTIVITY  DISCARD  ACK  SPDU 

AE  47  ACTIVITY  END  SPDU 

AEA  48  ACTIVITY  END  ACK  SPDU 

AI  49  ACTIVITY  INTERRUPT  SPDU 

AIA  50  ACTIVITY  INTERRUPT  ACK  SPDU 

AR  51  ACTIVITY  RESUME  SPDU 

AS  52  ACTIVITY  START  SPDU 

CD  53  CAPABILITY  DATA  SPDU 

CDA  54  CAPABILITY  DATA  ACK  SPDU 

ED  55  EXCEPTION  DATA  SPDU 

ER  56  EXCEPTION  REPORT  SPDU 

EX  57  EXPEDITED  DATA  SPDU 

FN-r  58  FINISH  -  reuse  SPDU 

GT  59  GIVE  TOKENS  SPDU 

GTA  60  GIVE  TOKENS  ACK  SPDU 

GTC  61  GIVE  TOKENS  CONFIRM  SPDU 

MAA  62  MAJOR  SYNC  ACK  SPDU 

MAP  63  MAJOR  SYNC  POINT  SPDU 

MIA  64  MAJOR  SYNC  ACK  SPDU 

MIP  65  MINOR  SYNC  POINT  SPDU 

NF  66  NOT  FINISHED  SPDU 

PR-MAA  67  PREPARE  (MAJOR  SYNC  ACK)  SPDU 

PR-RA  68  PREPARE  (RESYNCHRONIZE  ACK)  SPDU 

PR-RS  69  PREPARE  (RESYNCHRONIZE)  SPDU 

PT  70  PLEASE  TOKENS  SPDU  with  Token  Item 
Parameter 

RA  71  RESYNCHRONIZE  ACK  SPDU 

RF-r  72  REFUSE  -  reuse  SPDU 

RS-a  73  RESYNCHRONIZE  -  abandon  SPDU 

RS-r  74  RESYNCHRONIZE  -  restart  SPDU 

RS-s  75  RESYNCHRONIZE  -  set  SPDU 

TD  76  TYPED  DATA  SPDU 

CDO  77  CONNECT  DATA  OVERFLOW  SPDU 

OA  78  OVERFLOW  ACCEPT  SPDU 

PR-AB  79  PREPARE  (ABORT)  SPDU 
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14  APPENDIX  B:     OBJECT  IDENTIFIER  REGISTER 


5.14.1        Register  Index 

Each  entry  in  the  index  contains  an  object  identifier  value  and  a 
reference  to  the  section  describing  the  object  identifier's  use. 

1.  {   iso(l)  identif ied-organization(3)  oiw(14)  ulsig(8) 
application-context(l)  nil(l)   }  is  defined  in  section 
5.14.2. 

2,  {  iso(l)  identif ied-organization(3)  oiw(14)  ulsig(8) 
abstract-syntax(2)  octet-string(l)   )  is  defined  in  section 
5.14.2. 


5 . 14 . 2        Object  Identifier  Descriptions 

1.  {   iso(l)  identif ied-organization(3)  oiw(14)  ulsig(8) 
application-context( 1 )  nil(l)  ) 

This  application  context  may  be  used  by  applications  having 
a  prior  agreement  regarding  the  application  context. 

Note:  This  value  is  intended  to  be  used  by  private 

applications  that  have  an  a  priori  agreement 
concerning  the  set  of  ASEs,  related  options, 
and  any  other  information  necessary  for  the 
interworking  of  AEs  on  an  application 
association.  This  value  does  not  identify 
any  specific  application  context  and  cannot 
be  used  to  identify  the  intended 
communications  environment  for  the 
application  association.  Therefore,  it  is 
strongly  recommended  that  private 

applications  define  and  register  an  object 
identifier  for  their  application  context. 

2.  {  iso(l)  identif ied-organization(3)  oiw(14)  ulsig(8) 
abstract-syntax(2)  octet-string(l)  ) 

NIST-GIW-UtSIG-AS-  h==BEGIN 

octet-string -- -singte-oetet-string  h=-GGTET-STRING- 
DEFINITIGNS  END 

NIST-OIW-ULSIG-AS-octet- string 
DEFINITIONS  : :=  BEGIN 

Single-octet-string  : :=  OCTET  STRING 

END 
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This  abstract  syntax  may  be  used  by  applications  having  a 
prior  agreement  regarding  the  content  of  the  octet  string. 
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REGISTRATION   AUTHORITY    PROCEDURES    FOR   THE   OS I    IMPLEMENTORS  WORKSHOP 

Editor's  Note:  Previous  material  in  this  section  has  been  deleted  and 
is  no  longer  applicable. 

This  chapter  establishes  the  policies  and  procedures  for  the 
registration  of  technical  objects  defined  by  the  OSI  Implementors 
Workshop.  Procedures  for  registering  operational  and  administrative 
objects,  such  as  the  MHS  ADMD  and  PRMD  names  and  addresses,  are 
outside  the  scope  of  this  chapter. 

6.1     INTRODUCTION  AND  SCOPE 


6.1.1  What  is  Registration? 

In  order  to  communicate,  it  is  necessary  to  identify  the  objects 
involved  in  communication.  These  objects  have  names  and 
addresses.  A  name  identifies  an  object  within  the  domain  of  a 
registration  authority.  An  address  is  a  name  that  is  used  to 
specify  the  physical  or  logical  location  of  an  object, 

OSI  names  and  addresses  consist  of  attributes  which  are 
hierarchical  in  nature  and  which  combine  to  identify  or  locate  an 
OSI  object  unambiguously.  Since  the  relationship  between  the 
components  of  a  name  or  address  is  hierarchical,  it  follows  that 
the  registration  authority  for  names  and  addresses  should  also  be 
hierarchical.  A  governing  organization  does  not  always  have 
sufficient  knowledge  of  organizations  lower  in  the  hierarchy  to 
assign  values  within  those  organizations.  Thus,  an  approach 
frequently  taken  is  to  delegate  registration  authority  to  the 
lower  organizations . 

Hierarchy  implies  an  inverted  tree- like  structure  where  the 
number  of  objects  increases  from  the  root  of  the  tree  to  the 
leaves  of  the  tree.  At  the  root  of  the  tree,  there  is  one 
designator  that  has  the  greatest  scope  of  authority  (largest 
domain).  This  designator  assigns  identifier  values  to  objects 
under  its  authority.  Each  of  these  objects  has  a  smaller  scope 
of  authority  than  the  objects  immediately  above  and  may  create 
zero,  one,  or  many  subauthorities  at  the  next- lower  level.  The 
number  of  levels  in  such  a  tree -like  structure  is  arbitrary. 
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6.1.2  Scope 

This  chapter  defines  registration  procedures  for  OSI 
Implementors  Workshop  (OIW)  information  objects  and  identifies 
additional  registration  requirements.  These  procedures  shall  be 
used  by  the  Special  Interest  Groups  (SIGs)  of  the  Workshop  to 
register  information  objects  used  in  OSI  communications  according 
to  the  OIW  Agreements  Document. 

In  this  chapter,  the  OIW  and  the  SIGs  themselves  are  assigned 
arcs  in  the  object  identifier  tree.  These  arcs  are  for  OIW- 
specified  objects.  The  SIGs  should  note  that,  as  national  and 
international  registration  authorities  are  established,  objects 
of  interest  beyond  the  Workshop  are  more  appropriately  registered 
by  a  higher  level  in  the  hierarchy.  This  will  allow  more 
widespread  acceptance  of  the  registered  objects. 

This  chapter  is  structured  as  follows:  section  6.2  describes  the 
information  objects  that  need  to  be  registered.  Section  6.3 
describes  a  registration  procedures  for  OIW  object  identifiers. 
>  Appendix  A  lists  the  object  identifier  component  values  assigned 
to  the  OIW  and  the  SIGs.  Appendix  B  discusses  object 
identifiers  used  in  the  1987  and  1988  Stable  Implementation 
Agreements.  The  appendices  are  integral  parts  of  this 
specification. 

6.2     REGISTERED  INFORMATION  OBJECTS 

If  networks  are  to  interoperate  as  envisioned  in  the  OSI  model,  there 
must  be  a  universal  open  and  agreed  upon  naming  schema.  There  are 
many  information  objects  that  fall  under  this  requirement. 

Some  of  the  following  objects  are  registered  in  the  standards,  some 
are  registered  by  OIW  and  others  by  other  registration  authorities. 
An  example  list  of  objects  to  be  registered  is: 

o        Application-process- titles 
o        Application-entity- titles 
o       Abstract  syntaxes 
o        Transfer  syntaxes 
o  Application-contexts 
o  MHS 

ADMD  names 
PRMD  names 
Organization  names 
Encoded  information  types 
Extended  body  part  types 
Extensions 
etc . 
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o        Object  Identifier  values 
o        ASN.l  modules 
o  Directory 

Relative  distinguished  names 

Attribute  types 

Attribute  syntaxes 

Object  classes 

Encryption  algorithms 

etc . 

o  VT 

Profiles 

Reference  information  objects 
etc . 

o        Network  management  objects 
o        Network  layer  addresses 
o        System  titles 
o  FTAM 

Document  types 
Constraint  sets 
etc . 

o        etc . 

The  OIW  Registration  Authority  shall  only  administer  information 
objects  created  by  the  OIW  Agreements  Document  that  are  identified  by 
the  ASN.l  type  OBJECT  IDENTIFIER.  Figure  6.1  illustrates  the 
structure  of  the  object  identifier  component  value  for  OIW. 

{  iso    identif ied-organization    oiw(14)  } 

iso(l) 

identif ied-organization( 3) 

oiw(14) 

Figure  6.1.        Structure  of  Object  Identifier  for  OIW. 
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I  As  an  example  figure  6.2  shows  the  object  identifier  component  value 
I        for  an  example  object. 

{  iso    identified- organization  oiw(14)  rasig(13)  example(O)) 

iso(l) 

identif ied-organization(3) 

oiw(14) 

rasig(13) 

example (0) 

I  Figure  6.2.        Structure  of  an  Object   Identifier  for  an  Example 

I  Object  for  the  Registration  Authority  SIG  of  OIW. 

The  ISO  6523  Registration  Authority  has  assigned  an  International  Code 
Designator  (ICD)  value  of  14  to  OIW,  and  OIW  has  assigned  a  unique 
object  identifier  component  value  to  each  SIG.  The  assigned  object  ID 
values  for  the  OIW  and  for  each  SIG  are  in  Appendix  A.  The  assignment 
of  values  below  each  SIG  in  the  object  identifier  tree  is  the 
responsibility  of  that  SIG. 

6.3    REGISTRATION  PROCEDURES  FOR  OBJECT  IDENTIFIERS 

This  section  specifies  the  responsibilities  of  each  SIG  and  the 
procedures  to  be  followed  for  the  registration  of  information  objects, 
and  submission  to  the  OIW  Plenary. 

When  an  OIW  SIG  defines  an  information  object  the  SIG  shall  register 
the  object  identifier.  The  registered  value  shall  be  incorporated 
into  the  appropriate  OIW  Agreements  Document  as  a  result  of  a  positive 
ballot  response  of  the  OIW  Plenary, 

6.3.1  SIG  Registration  Authorization 

An  OIW  SIG  is  authorized  by  its  charter  and  the  scope  of  its  work 
to  submit  a  registration  request  to  the  OIW  Plenary. 

6.3.2  SIG  Registration  Authority  Function  and  Duties 
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The  SIG  Chair  is  responsible  for  the  assignment,  recording  and 
maintenance  of  the  SIG's  registered  objects.  The  SIG  Chair  may 
appoint  a  specific  person  to  carry  out  the  SIG  duties  and 
responsibilities . 

6.3.3         Requirements  for  Information  Object  Registration 

6.3.3.1  Assignment  of  Object  Identifier  Component  Values 

Each  SIG  shall  register  an  object  identifier  component  value 
for  each  object's  technical  definition.  The 
NameAndNumberForm  of  the  Obj IdComponent  specified  in  ISO 
8824/CCITT  X.208  is  used  exclusively.  This  form  comprises 
an  ASN.l  identifier  and,  significantly,  a  NumberForm. 

It  is  suggested  that  the  SIG  assign  a  monotonically 
increasing  integer  to  the  NumberForm  at  any  given  level.  To 
the  significant  root  the  SIG  shall  add  a  assigned  object 
identifier  component  value  that  shall  be  unique.  An  example 
of  an  object  identifier  created  by  the  RASIG  is  shown  as 
follows : 

{ iso(l)identified-organization(3)  oiw(14)  rasig(13)  example(O)} 

Teehnieal -Definitions 

Example  -PrintableStrtng  h  h="- 

'^This  -is  -an  -example .-" 

Here  rasig  is  the  SIG  identifier  and  13  is  the  NumberForm 
assigned  by  the  OIW  Registration  Authority  (see  Appendix  A) ; 
example  is  the  identifier  and  0  is  the  NumberForm  assigned 
by  the  RASIG. 

6.3.3.2  Proposal  of  Object  and  Identifier  to  Plenary 

Registration  of  an  object  identifier  and  its  definition  is 
proposed  by  inclusion  of  the  object  identifier  and  its 
definition  in  the  OIW  "Working  Implementation  Agreements" 
document . 
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6.3.3.3      Completion  of  Registration  Procedure 

Registration  of  an  object  identifier  and  its  definition  is 
completed  upon  Plenary  vote  to  move  "Working 
Implementation  Agreements"  text  which  contains  the  object 
identifier  and  its  definition  of  to  the  "Stable 
Implementation  Agreements"  document. 

■•  i    6.3.3.4      Changes   and  Revisions   to   the   Information  Object 
Registration 

Neither  the  technical  definition  nor  the  object  identifier 
shall  be  changed  or  modified  after  registration  i.e.,  after 
the  definitions  and  their  identifiers  have  been  voted  into 
the  "Stable  Implementation  Agreements"  document. 

6.3.4         Register  Index 

Each  SIG  shall  maintain  an  index  of  object  identifiers  that  point 
to  the  technical  definitions  of  the  respective  objects  in  the  OIW 
Agreements  Document.  The  index  shall  appear  in  the  appropriate 
chapter  annexes  of  the  OIW  Agreements  Document. 

Index  entry  example: 

Object  Identifier  Reference 

iso  identif ied-organization  Chapter  6.3.3.1 

oiw(14)  rasig(13)  example(O) 
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6.4    APPENDIX  A:     ASSIGNMENTS  TO  WORKSHOP  ORGANIZATIONS 


X  vJ-Cli  L.  X  X.  XO  I. 

W  X  w 

1  L 

^ri.oox^iicu    L.U    \-/xw  '-'y 

ISO  6523  RA") 

llsig 

1 

(Assigned  to  SIG  by  OIW) 

nmsig 

2 

secsig 

3 

tpsig 

4 

f tarns ig 

5 

mhsig 

6 

dssig 

7 

ulsig 

8 

rdasig 

9 

mmssig 

10 

odasig 

11 

vtsig 

12 

rasig 

13 
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6.5    APPENDIX  B:     STATUS  OF  1987  AND  1988  AD-HOC  OBJECT  IDENTIFIERS 


In  the  1987  and  1988  versions  of  the  Stable  Implementation  Agreements, 
a  number  of  OlW-specif ied  information  objects  are  assigned  object 
identifiers . 

OSI  requires  names  and  addresses,  e.g.,  object  identifiers,  be 
globally  unambiguous.  This  chapter  specifies  object  identifier 
component  values  which  are  globally  unambiguous.  Other  chapters  in 
this  document  specify  the  correct  object  identifiers  to  be  used  when 
referencing  OlW-specif ied  information  objects. 

The  use  of  the  1987  and  1988  OlW-specif  ied  object  identifiers  is 
deprecated.     Newly  defined  objects  shall  use  the  new  OIW  Identifier. 
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CCITT  1984  X.400  BASED  MESSAGE  HANDLING  SYSTEM 

Note:  The   classification   schema  used   in   the   chapter    (see  table 

7.7)  pre-dated  TR  10,000  and  was  the  basis  of  extensive 
harmonization,  as  such:  No  attempt  will  be  made  to  align 
this  chapter  with  TR  10,000. 

7.1  INTRODUCTION 

This  is  an  implementation  agreement  developed  by  the  Implementor ' s 
Workshop  sponsored  by  the  U.S.  National  Institute  of  Standards  and 
Technology  to  promote  the  useful  exchange  of  data  between  devices 
manufactured  by  different  vendors.  This  agreement  is  based  on,  and 
employs  protocols  developed  in  accord  with,  the  OSI  Reference  Model. 
While  this  agreement  introduces  no  new  protocols,  it  eliminates 
ambiguities  in  interpretations. 

This  is  an  implementation  agreement  for  a  Message  Handling  System 
(MHS)  based  on  the  X.400-series  of  Recommendations  (1984)  and  Version 
5  of  the  X.400  Series  Implementor ' s  Guide  from  the  CCITT.  It  is 
recommended  that  product  vendors  consult  later  versions  of  this  guide. 
Figure  7.1  displays  the  layered  structure  of  this  agreement. 

This  agreement  can  be  used  over  any  Transport  protocol  class.  In 
particular,  this  MHS  agreement  can  be  used  over  the  Transport  protocol 
class  0  used  over  CCITT  X.25,  described  in  section  5.2  of  this 
document.  In  addition,  this  MHS  agreement  can  be  used  over  the 
Transport  profiles  used  in  support  of  MAP  (Manufacturing  Automation 
Protocol)  or  TOP  (Technical  and  Office  Protocols).  Note  that  the  MAP 
or  TOP  environment  must  support  the  reduced  Basic  Activity  Subset 
(BAS)  as  defined  in  X.410. 

The  UAs  and  MTAs  require  access  to  directory  and  routing  services.  A 
Directory  Service  is  to  be  provided  for  each  (vendor-specific)  domain. 
Except  insofar  as  they  must  be  capable  of  providing  addressing  and 
routing  described  hereunder,  these  services  and  associated  protocols 
are  not  described  by  this  agreement. 
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User  Agent  Layer 

CCITT  X.420 

Message  Transfer  Agent  Layer 

CCITT  X.411 

Reliable  Transfer  Service  Layer 

CCITT  X.410 

Presentation  Layer 

CCITT  X.410 

Sec.  4.2 

Session  Layer 

See  section 

5.9 

Figure  7.1.  The  layered  structure  of  this  implementation  agreement. 
7 . 2  SCOPE 


This  agreement  applies  to  Private  Management  Domains  (PRMDs)  and 
Administration  Management  Domains  (ADMDs) .  Four  boundary  interfaces 
are  specified: 

(A)  PRMD  to  PRMD, 

(B)  PRMD  to  ADMD, 

(C)  ADMD  to  ADMD,  and 

i*:-  (D)  MTA  to  MTA  (within  a  PRMD,  e.g.,  for  MTAs  from  different 
.  :  vendors  . ) 

In  case  A,  the  PRMDs  do  not  make  use  of  MHS  services  provided  by  an 
ADMD.  In  cases  B  and  C,  UAs  associated  with  an  ADMD  can  be  the  source 
or  destination  for  messages.  Furthermore,  in  cases  A  and  B,  a  PRMD 
can  serve  as  a  relay  between  MDs ,  and  in  cases  B  and  C  an  ADMD  can 
serve  as  a  relay  between  MDs.  Figure  7.2  illustrates  the  interfaces 
to  which  the  agreement  applies. 

X.400  protocols  other  than  the  Message  Transfer  Protocol  (PI)  and  the 
Interpersonal  Messaging  Protocol  (P2)  are  beyond  the  scope  of  this 
agreement.  Issues  arising  from  the  use  of  other  protocols  or  relating 
to  PI  components  in  support  of  other  protocols  are  outside  the  scope 
of  this  document.  This  agreement  describes  the  minimum  level  of 
services  provided  at  each  interface  shown  in  figure  7.2.  Provision 
for  the  use  of  the  remaining  services  defined  in  the  X.400  Series  of 
Recommendations  is  outside  the  scope  of  this  document. 

With  the  exception  of  intra  domain  connections,  this  agreement  does 
not   cover   message   exchange   between   communicating   entities   within  a 
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domain  even  if  these  entities  communicate  via  PI  or  P2.  Bilateral 
agreements  between  domains  may  be  implemented  in  addition  to  the 
requirements  stated  in  this  document.  Conformance  to  this  agreement 
requires  the  ability  to  exchange  messages  without  use  of  bilateral 
agreements . 


PRMD  =  Private  Management  Domain 

ADMD  =  Administration  Management  Domain 


PRMD 


MTA 

A 

---D 

MTA 

B 

I 

A 


PRMD 


PRMD 


 B 


ADMD 


 C 


ADMD 


Figure  7.2.  This  agreement  applies  to  the  interface  between:  (A) 
PRMD  and  PRMD;  (B)  PRMD  and  ADMD;  (C)  ADMD  and  ADMD;  and 
(D)     MTA  and  MTA. 

7.3  STATUS 

This  version  of  the  X.400  based  Message  Handling  System  implementation 
agreements  was  completed  on  December  16,  1988.  No  further 
enhancements  will  be  made  to  this  version.  See  the  next 
section- -Errata. 


7.4  ERRATA 

Defect  report  material  may  be  in  this  section,  including  implementor 
agreement  versions  to  which  it  applies. 


7.5    PRMD  to  PRMD 

7.5.1  Introduction 

This  section  is  limited  in  scope  to  issues  arising  from  the  direct 
connection  (interface  A  in  fig.  7.2)  of  two  PRMDs .  "Direct"  means 
that  no  ADMD  or  relaying  PRMD  provides  MHS  services  to  facilitate 
message  interchange.  "Direct"  does  not  exclude  those  instances  for 
which  Administrations  happen  to  be  ADMDs  but  are  not  providing  X.400 
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services,  that  is,  they  are  used  only  to  provide  lower  layer  services 
such  as  X.25.  Figure  7.3  schematically  represents  the  scope  of  this 
section. 

These  issues  relate  to  the  use  of  the  UAL  (User  Agent  Layer)  and  MTL 
(Message  Transfer  Layer)  services,  protocol  elements,  recommended 
practices  and  constraints.  In  particular,  this  section  addresses  the 
PI  and  P2  protocols  and  their  related  services  in  a  direct  connection 
environment.  This  section  describes  the  minimum  level  of  services 
provided  by  a  PRMD.  Provision  for  the  use  of  the  remaining  services 
defined  in  the  X.400  Series  of  Recommendations  is  beyond  the  scope  of 
this  section. 


Private  Domain  X 
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UA 
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MTA 

<  
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^remainder 

Domain  X 
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P2 
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Private 

Domain  Y 

UA 

<— 

 > 

MTA 

 ^> 

/ 

\ 

iiiiithe 

iiiiremainder 
Domain  Y 
NETWORK 

of 

Figure  7.3.     Interconnection  of  private  domains. 

7.5.2        Service  Elements  and  Optional  User  Facilities 

This  section  identifies  those  service  elements  and  optional  user 
facilities  that  must  be  provided  in  support  of  Pi  and  P2 . 


7.5.2.1  Classification  of  Support  for  Services 

The  classification  of  UA  and  MT-Service  elements  is  used  to 
define  characteristics  of  equipment.  Equipment  can  claim 
SUPPORT  or  NON- SUPPORT  of  a  Service;  in  the  case  of 
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UA-service  elements,  a  separate  classification  is  given  for 
Origination  and  Reception. 

The  service  provider  is  defined  as  the  entity  providing  the 
service,  in  this  case,  the  MTL  or  the  UAL.  The  service  user 
is  either  the  MHS  user  or  the  UAL.  The  classification  of 
provider  and  user  relates  to  the  sublayer  for  which  the 
service  element  is  defined. 

7.5.2.1.1      Support  (S) 

a)  Support  means: 

o      The     service    provider    makes     the     service  element 
available  to  the  service  user,  and 

o  The  service  user  gives  adequate  support  to  the 
MHS  to  invoke  the  service  element  or  makes 
information  associated  with  the  service  element 
available . 

b)  Support  for  Origination  means  that: 

o  The  service  provider  makes  the  service  element 
available  to  the  service  user  for  invocation, 
and 

o  The  service  user  gives  adequate  support  to  the 
end  user  of  the  MHS  to  invoke  the  service 
element . 

c)  Support  for  Reception  means  that: 

o  The  service  provider  makes  information 
associated  with  the  service  element  available  to 
the  service  user. 

Note:  A  UA-  or  MT- service  element  can  carry 
information  from  originator  to  recipient  only 
if: 

o  the  service  element  is  available  to  the 
originator , 

o  the  service  element  is  available  to  the 
recipient,  and 

o      all  intermediate  steps  carry  the  information. 
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7.5.2. 1 .2  Non  Support  (N) 

This  means  that  the  service  provider  is  not  required  to 
make  the  service  element  available  to  the  service  user. 
However,  the  service  provider  should  not  regard  the 
occurrence  of  the  corresponding  protocol  elements  as  an 
error  and  should  be  able  to  relay  such  elements. 
Implementations  making  a  profile  available  should 
indicate  deviations  (additions  or  deletions)  with 
respect  to  the  requirement  in  the  profile. 

7.5.2.1.3  Not  Used  (N/U) 

This  means  that  although  the  Recommendation  allows  this 
service  element,   this  profile  does  not  use  it. 

7.5.2.1.4  Not  Applicable  (N/A) 

This  means  that  this  service  element  does  not  apply  in 
this  particular  case  (for  originator  or  recipient) . 

7.5.2.2  Summary  of  Supported  Services 

a)  Within  a  PRMD,  a  User  Agent  must  support  all  P2  BASIC 
IPM  Services  (X.400)  and  all  P2  ESSENTIAL  IPM  Optional 
user  facilities  (X.401)  subject  to  the  qualifiers  listed 
in  Appendix  7A. 

b)  Within  a  PRMD,  a  MTA  must  support  all  BASIC  MT  Services 
(X.400)  and  all  ESSENTIAL  MT  optional  user  facilities 
(X.401)  subject  to  the  qualifiers  listed  in  Appendix  7A. 

c)  No  support  is  required  of  the  additional  optional  user 
facilities  of  X.401. 


7.5.2.3  MT  Service  Elements  and  Optional  User  Facilities 

Tables  10.1  through  10.3  show  the  message  transfer  (MT) 
service  elements  and  optional  user  facilities. 
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Table  7.1.     Basic  MT  service  elements 


Support  (S)  or 

Service  Elements  Non-support  (N) 


Access  Management  N/U-*- 

Content  Type  Indication  S 

Converted  Indication  S 

Delivery  Time  Stamp  Indication  S 

Message  Identification  S 

Non-delivery  Notification  S 

Original  Encoded  Information  Types  Indication  S 

Registered  Encoded  Information  Types  N/U^ 

Submission  Time  Stamp  Indication  S 


■'■        Not  applicable  to  co-resident  UA  and  MTA. 

Table  7.2.      MT   optional   user   facilities   provided   to   the  UA-selectable   on  a 
per-message  basis 


Support  (S)  or 

MT  Optional  User  Facilities  Categorization    Non- support  (N) 


Alternate  Recipient  Allowed 

E 

S 

Conversion  Prohibition 

E 

S 

Deferred  Delivery 

E 

N 

Deferred  Delivery  Cancellation 

E 

N 

Delivery  Notification 

E 

S 

Disclosure  of  Other  Recipients 

E 

N 

Explicit  Conversion 

A 

N 

Grade  of  Delivery  Selection 

E 

S 

Multi-destination  Delivery 

E 

S 

Prevention  of  Non-delivery  Notification 

A 

N 

Probe 

E 

Return  of  Contents 

A 

N 
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Table  7.3.       MT   optional   user   facilities   provided   to    the   UA   agreed   for  any 
contractual  period  of  time 


Support  (S)  or 

MT  Optional  User  Facilities 

Categorization 

Non- Support  (N) 

Alternate  Recipient  Assignment 

A 

N 

Hold  for  Delivery 

A 

N/U 

Implicit  Conversion 

A 

N 

E:  Essential  optional  user  facility. 
A:  Additional  optional  user  facility. 

^    A  local  facility  subject  to  qualifiers  in  Appendix  7A. 

^     Support  not  required  for  an  originating  MT  user;    support  must  be  provided 

for  recipient  MT  users. 
^     Subject  to  qualifiers  in  Appendix  7A. 

7.5.2.4  IPM  Service  Elements  and  Optional  User  Facilities 

Tables  7.4  through  10.5  show  the  IPM  service  elements  and 
optional  user  facilities. 


-•I 
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Table  7.4.  Basic 

IPM  service 

/"\  1  /-\  rv\    ir\  i~  ^ 

Origination 

1?       on  t*  1  f\r\ 

IXC- ^C7Li  i^X^ll 

Service  Elements 

by  UAs 

Access  Management 

N/U^ 

Content  Type  Indication 

S 

Converted  Indication 

N/A 

s 

Delivery  Time  Stamp  Indication 

N/A 

s 

Message  Identification 

S 

s 

Non-delivery  Notification 

S 

N/A 

Original  Encoded  Information 

S 

S 

Types  Indication 

Registered  Encoded  Information  Types 

N/A 

N/A^ 

Submission  Time  Stamp  Indication 

S 

S 

IP-message  Identification 

S 

S 

Typed  Body 

S 

S 

Does  not  apply  to  co-resident  UA  and  MTA. 
Table  7.5.       IPM  optional  facilities  agreed  for  a  contractual  period  of  time 


Support  (S)  or 

Service  Elements  Categorization 

Non-Support  (N) 

Alternate  Recipient  Assignment  A 

N 

Hold  for  Delivery  A 

N 

Implicit  Conversion  A 

N 
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Table  7.6.     IPM  optional  user  facilities  selectable  on  a  per-message  basis 


Origination 

Reception 

IPM  Optional  User  Facilities 

by  UAs 

by  UAs 

Alternate  Recipient  Allowed 

A 

(N) 

A  (N) 

Authorizing    Users  Indication 

A 

(N) 

E  (S) 

Auto- forwarded  Indication 

A 

(N) 

E  (S) 

Blind  Copy  Recipient  Indication 

A 

(N) 

E  (S) 

Body  Part  Encryption  Indication 

A 

(N) 

E  (S) 

Conversion  Prohibition 

E 

(S) 

E  (S) 

Cross-referencing  Indication 

A 

(N) 

E  (S) 

Deferred  Delivery 

E 

(N)6 

N/A 

Deferred  Delivery  Cancellation 

A 

(N/U)^ 

N/A 

Delivery  Notification 

E 

(S) 

N/A 

Disclosure  of  Other  Recipients 

A 

(N) 

E  (S) 

Expiry  Date  Indication 

A 

(N) 

E  (S) 

Explicit  Conversion 

A 

(N) 

N/A 

Forwarded  IP-message  Indication 

A 

(N) 

E  (S) 

Grade  of  Delivery  Selection 

E 

(S) 

E  (S) 

Importance  Indication 

A 

(N) 

E  (S) 

Multi-destination  Delivery 

E 

(S) 

N/A 

Multi-part  Body 

A 

(N) 

E  (S) 

Non-receipt  Notification 

A 

(N) 

A  (N) 

Obsoleting  Indication 

A 

(N) 

E  (S) 

Originator  Indication 

E 

(S) 

E  (S) 

Prevention  of  Non-delivery  Notification 

A 

(N) 

N/A 

Primary  and  Copy  Recipients  Indication 

E 

(S) 

E  (S) 

Probe 

A 

(N) 

N/A 

Receipt  Notification 

A 

(N) 

A  (N) 

Reply  Request  Indication 

A 

(N) 

E  (S) 

Replying  IP-message  Indication 

E 

(S) 

E  (S) 

Return  of  Contents 

A 

(N) 

N/A 

Sensitivity  Indication 

A 

(N) 

E  (S) 

Subject  Indication 

E 

(S) 

E  (S) 

A  local  facility  subject  to  qualifiers  in  Appendix  7A. 
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7.5.3        X.400  Protocol  Definitions 

This  section  reflects  the  agreements  of  the  NIST/OSI  Workshop 
regarding  PI  and  P2  protocol  elements. 

7.5.3.1  Protocol  Classification 

The  protocol  classifications  are  defined  below  in  table  7.7: 
Table  7.7.     Protocol  Classifications 


1)  UNSUPPORTED  =  X 

These  elements  may  be  generated,  but  no  specific  processing  should 
be  expected  in  a  relaying  or  delivering  domain.     A  relaying  domain 
must  at  least  relay  the  semantics  of  the  element.     The  absence  of 
these  elements  should  not  be  assumed,  in  a  relaying  or  delivering 
domain,  to  convey  any  significance. 

2)  SUPPORTED  ^  H 

These  elements  may  be  generated.     However,   implementations  are  not 
required  to  be  able  to  generate  these  elements.  Appropriate 
actions  shall  be  taken  in  a  relaying  or  delivering  domain. 

3)  GENERATABLE  =  G 

Implementations  must  be  able  to  generate  and  handle  these  protocol 
elements,  although  they  are  not  necessarily  present  in  all 
messages  generated  by  implementations  of  this  profile. 
Appropriate  actions  shall  be  taken  in  a  relaying  or  delivering 
domain. 

4)  REQUIRED  =  R 

Implementations  of  this  profile  must  always  generate  this  protocol 
element.     However,   its  absence  cannot  be  regarded  as  a  protocol 
violation  as  other  MHS  implementations  may  not  require  this 
protocol  element.     Appropriate  actions  shall  be  taken  in  a 
relaying  or  delivering  domain. 

5)  MANDATORY  =  M 

This  must  occur  in  each  message  as  per  X.411  or  X,420  as 
appropriate;  absence  is  a  protocol  violation.     Appropriate  actions 
shall  be  taken  in  a  relaying  or  delivering  domain. 
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7.5.3.2  General  Statements  on  Pragmatic  Constraints 

a)  Where  a  protocol  element  is  defined  as  a  choice  of 
Numeric  String  and  Printable  String  (i.e., 
Administration  Domain  Name  and  Private  Domain 
Identifier) ,  then  a  numeric  value  encoded  as  a  printable 
string  is  equivalent  to  the  same  value  encoded  as  a 
numeric  string.  This  does  not  apply  to  the  Country  Name 
protocol  element. 

b)  The  maximum  number  of  recipients  in  a  single  MPDU  is  32K 
-  1  (that  is,  32767).  However,  no  individual  limits  on 
the  number  of  occurrences  (recipients)  are  placed  on  the 
following  protocol  elements:  Authorizing  Users,  Primary 
Recipients,  Copy  Recipients,  Blind  Copy  Recipients, 
Obsoletes  and  Cross  References.  Additionally,  there  is 
no  limit  on  the  number  of  Reply  to  Users.  This  is  a 
local  matter  for  the  originating  system. 

c)  Use  of  strings.  A  Printable  String  is  defined  in  terms 
of  the  number  of  characters ,  which  is  the  same  number  of 
octets.  For  T.61  strings  the  number  of  octets  is  twice 
the  number  of  characters  specified. 

d)  The  ability  to  generate  maximum  size  elements  is  not 
required,  with  the  exception  of  the  component  fields  in 
the  Standard  Attribute  List,  in  which  case  it  is 
required. 

7.5.3.3  MPDU  Size 

The  following  agreements  govern  the  size  of  MPDUs: 

o  All  MTAEs  must  support  at  least  one  MPDU  of  at  least  two 
megabyte ,  and 

o  The  size  of  the  largest  MPDU  supported  by  a  UAE  is  a 
local  matter. 


7.5.3.4  PI  Protocol  Elements 


7.5.3.4.1      PI  Envelope  Protocol  Elements 

Table  7.8  contains  Protocol  Elements  and  their  classes. 
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Table  7.8. 

PI 

protocol  elements 

Element 

Class 

Restrictions  and  Comments 

MPDU 

UserMPDU 

G 

Del 1 ve  r yRep  o  r  tMPDU 

G 

ProbeMPDU 

H 

UserMDPU 

UMPDUEnvelope 

M 

UMPDUContent 

M 

UMPDUEnvelope 

MPDUIdentifier 

M 

originator  ORname 

M 

originalEncodedlnformationTyp 

es  G 

If  this  field  is  absent,  then  the 

Encoded  Information  Type  is 

"unspecified. " 

ContentTjrpe 

M 

H 

Priority 

G 

PerMessageFlag 

G 

Maximum  length  =  2  octets. 

deferredDe livery 

X 

PerDomainBilaterallnfo 

X 

No  limit  on  number  of  occurrences . 

Recipientlnfo 

M 

Maximum  number  =  32K  -  1  occurr- 

ences. More  severe  limitations  are 

by  bilateral  agreement. 

Tracelnformation 

M 

UMPDUContent 

M 

MPDIITdpnti  f  1  er 

GlobalDomainldentif ier 

M 

lASString 

M 

Maximum  length  =  32  characters, 

graphical  subset  only.     Refer  to 

T.50  for  clarification  of  graphical 

PerMessageFlag 

subset . 

discloseRecipients 

H 

conversionProhibited 

G 

alternateRecipientAl lowed 

H 

contentReturnRequest 

X 

(Continued  on  next  page.) 
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Table  7.8. 

PI  protocol 

elements,  Continued 

Element 

Class 

Restrictions  and  Comments 

PerDomainBilateralInf o 

CountryName 

M 

Maximum  length  =  3  characters. 

AdrainistrationDomainName 

M 

Maximum  length  =  16  characters. 

Bilateral Info 

M 

Maximum  depth  =  8 ;  maximum 
length  =  1024  octets 
(including  encoding). 

Recipientinf o 

recipient 

M 

Extens ionldentif ier 

M 

Maximum  value  =  32K  -  1  (32767). 

perRecip lent Flag 

M 

Maximum  length  =  2  octets. 

1  1           -1_  _L  V  .  j_  I —  \j  V  i  I  V       ^  O  ^  V>  1 1 

Y 

perRecip ientFlag 

ResponsibilityFlag 

M 

ReportReques t 

M 

II  p  tR  pnoT  t"R  p  niip  <>  t 

\J  %J        X,  LVV^  VJ  \J  J_        J- V  V-^  vJ  wA  •w'  >J  ^ 

M 

Tracelnf ormat i  on 

RpfpTpnf  p   'sboul  d  bp  madp  to 
Version  5  of  the  X.400  Imple- 
mentor's  Guide  for  information 

GlobalDomainldentif  ier 

M 

related  to  Trace  sequencing. 

DomainSuppliedInf o 

M 

DomainSuppliedInf o 

arrival 

M 

deferred 

X 

action 

M 

0=relayed  (value) 

G 

l=rerouted  (value) 

H 

Rerouting  is  not  required. 

converted 

H 

previous 

H 

ORNamp 

cpr»t-ion   7    S    3  S 

EncodedlnformationTypes 

bit  string 

■( 

M 

Delivery  can  only  occur  if  match 
is  made  with  Registered  Encoded 
Information  Types.  Individual 
vendors  may  impose  limits. 
Maximum  length  =  4  octets. 

G3NonBasicParameters 

X 

TeletexNonBasicParameters 

X 

PresentationCapabilities 

X 

(Continued  on  next  page.) 
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Table  7.8.     PI  protocol  elements,  Continued 


Element 

Class 

Restrictions  and  Comments 

Del i ve  ry Rep  o  r  tMPDU 

DeliveryReport Envelope 

M 

De  1  ivervReDortContpnt' 

M 

DeliveryReportEnvelope 

report 

M 

originator 

M 

Traceinf ormat ion 

M 

De 1 iveryRepor tContent 

original 

M 

intermediate 

G 

See  comment  at  end  of  table. 

UAContentID 

G 

ReportedRecipientlnfo 

M 

Maximum  number  =  32K  ~  1 

occurrences . 

returned 

H 

Can  only  be  issued  if  specifically 

requested  in  the  originating 

message . 

billinginf ormat ion 

X 

Maximum  depth  =  8 ;  maximum 

length  =  1024  octets  (including 

encoding) . 

ReportedRecipientlnfo 

recipient 

M 

Extensions Identifier 

M 

PerRecip lent Flag 

M 

Las tTrace Information 

M 

intendedRecipient 

H 

Supplementaryinf ormat ion 

V 

A 

Maximum  length  =  64  characters. 

Value  is  pending  verification  by 

the  CCITT  SG  VIII  or  XI. 

Las tTraceInf ormat ion 

arrival 

M 

converted 

G 

Report 

M 

(Continued  on  next  page. 
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Table  7.8.     Pi  protocol  elements,  continued 


Element 

Class 

Restrictions  and  Comments 

Report 

Deliveredlnfo 

G 

Generated  if  delivery  is  reported. 

Nonde 1 iveredinf o 

G 

Generated  if  failure  to  deliver 

is  reported. 

UG  J.iVcircOJ.IlZO 

ae 1 ivery 

M 

typeofUA 

K 

This  element  must  be  generated  with 

a  PRIVATE  value  by  PRMDs . 

NonDe 1 iveredinf o 

ReasonCode 

M 

DiagnosticCode 

H 

Whenever  possible,  use  a  meaningful 

diagnostic  code. 

ProbeEnvelope 

probe 

M 

originator 

M 

ContentType 

sfl 

UAContentID 

H 

• 

Maximum  length  =  16  characters. 

original 

If  this  field  is  absent,  then  the 

Encoded  Information  Type  is 

"unspecified. " 

Tracelnformation 

M 

PerMessageFlag 

G 

contentLength 

H 

PerDomainBilaterallnfo 

X 

Recipientlnfo 

M 

Maximum  number  =  32K  -  1 

occurrences . 

GlobalDoraainldentif ier 

CountryName 

M 

Maximum  length  =  3  characters. 

AdministrationDomainName 

(4) 

M 

Maximum  length  -  16  characters  or 

digits . 

PrivateDomainldentif ier 

R 

Maximum  length  =  16  characters  or 

digits.     This  element  must  be 

generated  by  PRMDs . 

End 

of  Definitions 
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Notes  on  table  7.8 

Coinment  on  intermediate  Tracelnformation  in  the 
DeliveryReportContent  in  table  7.8:  Audit  and  confirmed  reports 
should  not  be  requested  by  other  than  the  originating  domain  for 
two  reasons.  First,  the  return  path  of  the  report  may  be 
different  from  the  path  taken  by  the  original  message,  and  it  may 
exclude  the  domain  that  added  the  request  for  audit  and  confirmed 
to  the  message.  Second,  if  the  return  path  is  different  from  the 
path  of  the  original  message,  the  originating  domain  would 
receive  intermediate  trace  information  that  it  did  not  request. 

7.5.3.5  ORName  Protocol  Elements 

Only  form  1  variant  1  0/R  names  are  supported. 

Table  7.9  contains  ORName  protocol  elements. 

These  agreements  interpret  1984  X.400  section  3.4  to  mean 
that  the  attributes  in  the  ORName  in  the  MPDU  must  identify 
exactly  one  UA,  and  that  all  the  values  for  the  attributes 
specified  in  the  ORName  must  be  identical  to  the  values  of 
the  corresponding  attributes  associated  with  the  recipient 
UA.  Underspecif led  names  that  are  unique  are  deliverable. 

Overspecif led  ORNames,  ORNames  with  mismatching  fields,  and 
ambiguous  names  are  to  be  non- delivered  or  sent  to  the 
alternate  recipient  as  appropriate. 
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Table  7.9.     ORName  protocol  elements 


J-jJ-dlLdlL. 

Place 

R o c  ^ T" T t"  1  r^n c    anH  (^rMnmont'o 
tvc o  UX  XL-  L.X(Jl1o     ctilU    V^UUUIlc:; il L. o 

nPNTamo 

C  t~  o  "n      'a  "V"     A  "f"         T  V\i  1  ^  A  T  T  ^ 

M 

T^r^m^i  1  nT^^ "F T       H A t" t"T"  1  Vii  1 1" ^ T  i  ct" 

Y 
£i. 

Q  t- anH  a  Y"H  A  f- f- VT  Kn  t-oT  ic-h     ^^  ^ 

o  uaiitiaL  uj\c.  ul  x du. J-ij. s  l.   \  ^  j 

U UIl  L  L  y  IN  cilllc 

P 

I\. 

A  o     ^  o     1  n  A         1  n     Y     /111         M  a  V  n  mi  i  vn 
r\S    UcXXllcU.    XII    A.M-XX  ,  ila-XXIItUJU 

j.engcn  —  ->  cnaracLeLS. 

rtomiuis tratxonuomaiiuName 

P 

Maximum  length  =  16  characters 

or  digits. 

X12lAddress 

X 

Maximum  length  =  15  digits. 

Tprmi       1  TD                              "  . 

X      i.  Ill  J-  i  Id  X  X  1^ 

Y 

1  Id  A.  XllIUJIl     XCilE.L.il     ~     £-'-r         1  id  X  CL^  L.  w  X  o  . 

ri 
\j 

Msj  V  T  mi  im     loncTt"n    —     \  r\    r*\\  a     a  r*  f'  ^  y  c 

ridAxiiicuii   xcii^L-ii  —   xu  ciidXdL'Ccxo. 

OrganizationName  (2) 

G 

Maximum  length  =  64  characters. 

UniqueUAIdentif ier 

X 

Maximum  length  =  32  digits. 

rcL  sonaxiName 

p 

VJ 

naximum  i.engcn  ot  vaj.ues  ol  sud 

exemenus  —  dm-  ciiaLac lcits  . 

Note:     The  possibility  that  this 

value  may  be  reduced  to  40 

cnaracuers  is  lor  lurtner 

CI 

ria-Xxmuni  xcriguii  —  dl.  dicixcicucxb  pci 

C/C     IXX  X  C  Ll(^  C  .         t\    UldAXUlLlUl    (J  J_  i.ULli- 

^    1 1       o       o  o     o  Y~  o    all  m  t.t  o  r\ 

DomainDef inedAttributeList  (5) 

Maximum  =  4  occurrences. 

type 

M 

Maximum  length  =  8  characters. 

value 

M 

Maximum  length  =  128  characters. 

PersonalName 

surName 

M 

Maximum  length  =  40  characters. 

givenName 

G 

Maximum  length  =  16  characters. 

initials 

G 

Maximum  length  =    5  characters; 

excluding  surname  initial  and 

punctuation  and  spaces. 

generationQualif ier 

G 

Maximum  length  =  3  characters. 

(Continued  on  next  page.) 
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Table  7.9.     ORName  Protocol  Elements,  Continued 

Notes : 

1.  The  following  apply  for  comparison  of  the  Standard  Attributes  of 
an  0/R  Name: 

a.  Lower  case  is  interpreted  as  upper  case  (for  IA5) . 

b.  Multiple  spaces  may  be  interpreted  as  a  single  space. 
Originating  domains  shall  only  transmit  single  significant 
spaces.  If  multiple  spaces  are  transmitted,  non-delivery 
may  occur . 

2.  At  least  one  of  these  must  be  supplied. 

3.  These  should  be  sent  in  descending  sequence,  from  the  most 
significant  <Organizational  Unit>  (highest  in  organization 
hierarchy)  to  the  least  significant.  Only  those  specified 
should  be  sent.  (That  is,  an  unspecified  <Organizational  Unit> 
should  not  be  sent  along  as  a  field  of  [null]  content,  nor  zero 
length ,  etc . ) 

4.  This  attribute  shall  contain  one  space  in  all  ORNames  of  messages 
originated  in  a  PRMD  that  is  not  connected  to  an  ADMD,  and  in 
ORNames  of  recipients  reachable  only  through  a  PRMD;  otherwise, 
this  attribute  shall  contain  an  appropriate  ADMD  name. 

5.  Some  existing  systems  which  will  be  accessed  via  an  X.400  service 
(whether  directly  connected  using  X.400  protocols  or  otherwise) 
may  require  the  provision  of  addressing  attributes  which  are  not 
adequately  supported  by  Standard  Attributes  as  defined  in  these 
Agreements.  In  such  cases,  Domain  Defined  Attributes  are  an 
acceptable  means  of  carrying  additional  addressing  information. 
Failure  to  support  the  specification  and  relaying  of  DDAs  may 
prevent  successful  interworking  with  such  existing  systems  until 
such  time  as  all  systems  are  capable  of  relaying  and  delivery 
using  only  the  Standard  Attribute  list.  Specific  recommendations 
on  the  use  of  DDAs  for  particular  applications  are  in  the 
Recommended  Practices  section  7.12,  Appendix  B. 

7.5.3.6  P2  Protocol  Profile  (Based  on  fX.420n 

Tables  7.10  and  7.11  classify  the  support  for  the  P2 
protocol  elements  required  by  this  profile.  The  tables 
give  restrictions  and  comments  in  addition  to  X.420. 

Restriction  on   length  is  one  of  the  types  of  restrictions. 
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The  reaction  of  implementations  to  a  violation  of  this 
restriction  is  not  defined  by  this  Profile. 

.1     7.5.3.6.1      P2  Protocol  -  Heading 

Table  7.10  below  specifies  the  support  for  protocol 
elements  in  P2  Headings. 

Table  7.10.      P2  heading  protocol  elements 


Element 

Class 

Restrictions  and  Comments 

UAPDU 

IM-UAPDU 

G 

SR-UAPDU 

X 

IM-UAPDU 

Heading 

M 

Body 

M 

Heading 

IPMessageld 

M 

originator 

R 

author izingUsers 

H 

primaryRecipients 

G 

At  least  one  of  primaryRecipients, 

copyRecipients 

G 

copyRecipients,  or 
blindCopyRecipients  must  be 

blindCopyRecipients 

H 

present . 

inReplyTo 

G 

obsoletes 

H 

crossReferences 

H 

subject 

G 

Maximum  length  =  128  T.61 
characters  (256  octets); the  ability 
to  generate  the  maximum  size 
subject  is  not  required. 

expiryDate 

H 

reply By 

H 

replyToUsers 

H 

importance 

H 

Appropriate  action  is  for  further 
s  tudy . 

sensitivity 

H 

Appropriate  action  is  for  further 
study. 

autoforwarded 

H 

(Continued  on  next  page.) 
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Table  7.10,     P2  heading  protocol  elements,  continued 


Element 

Class 

Restrictions  and  Comments 

IPmessageld 

ORName 

H 

PrintableString 

M 

Maximum  length  =  64  characters. 

ORDescriptor 

ORName 

H 

Specify  the  ORName  whenever  it  is 

possible.     See  Appendix  7B. 

f reef ormName 

H 

Maximum  length  =  64  characters, 

graphical  subset  only  (128  octets.) 

t  e  1  e  pli  one  Numb  e  r 

H 

Maximum  length  =  32  characters . 

This  allows  for  punctuation.  It 

does  not  take  into  account  possible 

future  use  by  ISDN. 

Recipient 

ORDescriptor 

M 

reportRequest 

X 

replyRequest 

H 

Body 

No  limit  on  number  of  BodyParts. 

BodyPart 

G 

No  limit  on  length  of  any  BodyPart 

or  the  depth  of  ForwardedlPMessage 

BodyParts  nested.  Classification  is 

subject  to  pending  CCITT  resolution 

SR-UAPDU 

nonReceipt 

H 

receipt 

H 

reported 

M 

actualRecipient 

R 

intendedRecipient 

H 

converted 

X 

NonReceiptlnformation 

reason 

M 

nonReceiptQualif ier 

H 

comments 

H 

Maximum  length  =  256  characters. 

returned 

H 

May  only  be  issued  if  specifically 

requested  by  originator. 

(Continued  on  next  page.) 
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Table  7.10.     P2  heading  protocol  elements,  continued 


Element 

Class 

Restrictions  and  Comments 

Receipt Information 

receipt 

M 

typeOfReceipt 

H 

Supplementarylnformation 

X 

Maximum  length  =  64  characters . 

Note:     This  value  is  pending 

verification  by  the  CCITT  SG 

1,  

VIII  or  IX. 

End 

of  Definitions 

7.5.3.6.2      P2  Protocol  -  BodyParts 

a)  All  BodyParts  with  identifiers  in  the  range  0  up  to 
and  including  16K  -1  are  legal  and  should  be 
relayed.  BodyPart  identifiers  corresponding  to 
X.121  Country  Codes  should  be  interpreted  as 
described  in  Note  2  of  figure  7.4. 

o  Implementations  are  required  to  generate  and 
image  lASText. 

o  Implementations  should  specify  the  other 
BodyPart  types  supported. 

o  If  an  implementation  supports  a  particular 
BodyPart  type  for  reception,  it  should  also  be 
able  to  support  that  BodyPart  type  for  reception 
if  it  is  part  of  a  ForwardedlPMessage . 

o  For  the  BodyPart  types  currently  considered, 
support  for  the  protocol  elements  is  as 
indicated  in  table  7.11. 

b)  Privately  Defined  BodyParts 

This  section  describes  an  interim  means  for  identifying 
privately  defined  BodyParts.  This  section  shall  be 
replaced  in  a  future  version  taking  into  account  CCITT 
recommendations  with  equivalent  functionality. 
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BodyPart     : :  =    CHOICE  { 

[0] IMPLICIT  lASText, 

[1] IMPLICIT  TLX, 


[234] IMPLICIT  UKBodyParts, 
[310] IMPLICIT  USABodyParts , 

) 

Where  UKBodyParts  and  USABodyParts  are  defined  as 
SEQUENCE  {BodyPartNumber,  ANY) 
BodyPartNumber  : :=  INTEGER 


Note  1:     In  the  EncodedlnformationTypes  of  the  Pi  Enveiope,  the 
undefined  bit  must  be  set  when  a  message  contains  a 
privately  defined  BodyPart.     Each  UA  that  expects  such 
BodyParts  should  include  undefined  in  the  set  of 
deliverable  EncodedlnformationTypes  it  registers  with  the 
MTA. 

Note  2:    All  BodyPartNumbers  assigned  must  be  interpreted  relative 
to  the  BodyPart  in  which  they  are  used,  which  is  that 
tagged  with  the  value  [310]  for  those  defined  within  the 
United  States.     The  NIST  assigns  unique  message 
BodyPartNumbers  for  privately  defined  formats  within  the 
United  States. 

Note  3:     Refer  to  section  7.12.6  for  recommendations  regarding  the 
implementaion  of  USABodyParts, 


Figure  7.4.    X.409  Definition  of  Privately  Defined  BodyParts. 
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7.5.3.6.3  P2 

BodyPart 

Protocol  Elements 

Table 

7.11. 

P2  BodyParts 

Elements 

Class 

Restrictions  and  Comments 

BodyPart 

lASText 

G 

TLX 

X 

Voice 

X 

G3Fax 

X 

TIFO 

X 

TTX 

X 

Videotex 

X 

NationallyDe fined 

X 

Encrypted 

X 

ForwardedlPMessage 

H 

SFD 

X 

TIFl 

X 

unidentified 

X 

IA5Text 

repertoire 

H 

lASString 

M 

For  rendition  of  lASText  see 

Appendix  7C. 

TLX 

For  further  study  by  CCITT. 

Voice 

Set 

For  further  study  by  CCITT, 

BitString 

M 

G3Fax 

numberOf Pages 

X 

PI .G3NonBasicParameters 

X 

SEQUENCE  (OF  BIT  STRING) 

M 

BIT  STRING 

H 

See  Note. 

PI . G3NonBasicParameters 

Support  for  individual  elements  is 

for  further  study. 

TIFO 

T . 73Document 

M 

T . 73ProtocolElement 

H 

See  Note. 

(Continued  on  next  page.) 
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Table  7.11.       P2  BodyParts ,  continued 


Elements 

Class 

Restrictions 

and  Comments 

TTX 

numberOf Pages 

X 

telexCompatible 

X 

PI . TeletexNonBasicParams 

X 

SEQUENCE 

M 

T61S tring 

H 

See  Note. 

PI .TeletexNonBasicParams 

graphicCharacterSets 

X 

controlCharacterSets 

X 

pageFormats 

X 

miscTerminalCapabilities 

X 

privateUse 

X 

Videotex 

SET 

For  further 

study  by  CCITT. 

Video texS tring 

M 

NationailyDef ined 

ANY 

M 

Encrypted 

SET 

For  further 

study  by  CCITT. 

BIT  STRING 

M 

ForwardedlPMessage 

delivery 

H 

De 1 i very Information 

H 

IM-UAPDU 

M 

Deliverylnformation 

PI . ContentType 

M 

originator 

M 

original 

M 

PI . Priority 

G 

DeliveryFlags 

M 

otherRecipients 

H 

thisRecipient 

M 

intendedRecipient 

H 

converted 

X 

submission 

M 

(Continued  on  next  page.) 
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Table  7.11.     P2  BodyParts ,  continued 


Elements  Class  Restrictions  and  Comments 


SFD 

SFD. Document  M 
TIFl 

T73  Document  M 

T73 . ProtocolElement  H  See  note 


Note:     This  element  is  not  an  addition  to  the  definition  of  the  BodyPart. 
It  is  described  here  to  show  that  the  SEQUENCE  may  contain  zero 
elements.     A  Problem  Report  has  been  submitted  to  the  CCITT  to 
clarify  whether  this  is  permissible.     The  NIST/OSI  Workshop 
will  adopt  the  CCITT  decision. 


7.5.4        Reliable  Transfer  Server  (RTS^ 

7.5.4.1  Implementation  Strategy 

Based  on  X.410  Clause  3  and  X.411  Clause  3.5. 


7.5.4.2  RTS  option  selection 

a)  The  maximum  number  of  simultaneous  associations  is  not 
limited  in  this  profile;  if  the  capacity  of  a  system  is 
exceeded,  it  should  not  initiate  or  accept  additional 
associations . 

b)  Associations  are  established  by  the  MTA  which  has 
messages  to  transfer. 

c)  Associations  are  released  when  they  are  not  needed. 
Associations  may  also  be  ended  prematurely  due  to 
internal  problems  of  the  RTS. 

d)  For  both  monologue  and  two  way  alternate  associations, 
the  initiator  keeps  the  initial  turn. 

e)  When  establishing  an  RTS  association,  the  following 
rules  apply  to  the  use  of  parameters  in  addition  to 
those  in  X.410  Clause  3.2.1: 
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Dialogue  mode:  Monologue  must  be  supported  for  this 
profile;  two-way  alternate  is  used  only 
if  both  partners  agree. 

Initial  turn:  Kept  by  the  initiator  of  the 
association. 

f)  The  'priority-mechanism'  and  the  ' transfer- time  limit' 
are  regarded  as  local  matters. 

7.5.4.3  RTS  Protocol  Options  and  Clarifications 

Realization  of  the  RTS  protocol  is  subject  to  the  following 
rules  in  addition  to  those  specified  in  X.410  Clause  4: 

a)  One  RTS  association  corresponds  to  one  or  more 
consecutive  session  connections  (not  concurrent  ones) . 
The  first  is  opened  with  ConnectionData  of  type  OPEN, 
and  subsequent  ones  are  opened  with  type  RECOVER. 

b)  Recovery  of  a  Session  connection  is  only  by  RTS 
initiator. 

c)  Checkpoint  size: 

o  Checkpointing  and  No  Checkpointing  should  be 
supported.  Whenever  possible,  checkpointing  should 
be  used. 

o  The  minimum  checkpointSize  is  1  (that  is,  1024 
octets) . 

d)  Window  size: 

o      Minimal  value  of  1  (if  checkpointing  is  supported) . 

o  WindowSize  =  1  means:  After  an  S-SYNCH-MINOR 
request  is  sent,  wait  until  the  confirmation  is 
received  before  issuing  an  S-DATA,  S-SYNCH-MINOR,  or 
S -ACTIVITY- END  request. 

e)  APDUs  should  not  be  blocked  into  one  activity. 

f)  Only  one  SSDU  shall  be  transferred: 

o      Between  two  adjacent  minor  synch  points. 

o  Between  minor  synch  points  and  adjacent 
S -ACTIVITY- START  and  S -ACTIVITY- END  requests. 
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o  Between  S -ACTIVITY- START  and  S -ACTIVITY- END  without 
checkpoints . 

A  monologue  association  is  defined  as  follows: 

o  The  RTS  user  responsible  for  establishing  the 
association  is  called  the  initiator. 

o      The  initiator  keeps  the  initial  turn. 

o  APDUs  are  transferred  in  the  direction  of  the 
initiator  to  the  recipient  only. 

o      There  shall  be  no  token  passing. 

o  Only  the  initiator  can  effect  an  orderly  release  of 
the  association. 

A  two-way  alternate  association  is  as  described  in 
X.410. 

In  the  UserData  parameter  of  the  S-U- ABORT,  the 
Ref  lectedParameter  will  not  be  used  in  the 
Abortlnformation  element. 

When  the  S -ACTIVITY-RESUME  is  used  to  resume  an  activity 
in  the  same  session  connection  as  the  one  in  which  it 
started,  this  must  happen  immediately  after  the  activity 
has  been  interrupted  (i.e.,  no  intervening  activity  can 
occur).  Otherwise,  X.410  Clause  4.3  paragraph  1  may  be 
violated. 

When  S -ACTIVITY-RESUME  is  used  to  resume  an  activity 
started  in  another  session  connection,  the  following 
conditions  must  be  met: 

o      The  current  session  connection  is  of  type  "recover." 

o  The  value  of  OldSessionConnectionldentif ier  in 
S -ACTIVITY-RESUME  must  match  the  value  of  the 
SessionConnectionldentif ier  parameter  used  in  the 
S-CONNECT  of  the  prior  session  connection.  This 
value  is  also  identical  to  the 

SessionConnectionldentif ier  in  the  ConnectionData 
(in  PConnect,  in  SS-UserData)  for  the  current 
session  connection. 

o  This  must  occur  as  the  first  activity  of  the  next 
session  connection  for  the  same  RTS-association.  It 
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must  be  the  first,  otherwise  X.410  Clause  4.5.1 
point  1  is  violated. 

Note:  It  is  in  the  same  RTS -ASSOCIATION  because  the  use  of 
S -ACTIVITY-RESUME  only  makes  sense  within  the  scope 
of  one  RTS  association. 

1)  If  the  transfer  of  an  APDU  is  interrupted  before  the 
confirmation  of  the  first  checkpoint,  the  value  of  the 
SynchronizationPointSerialNumber  in  S -ACTIVITY-RESUME 
should  be  zero,  and  the  S -ACTIVITY-RESUME  must  be 
immediately  followed  by  an  S -ACTIVITY-DISCARD. 

m)  In  S -TOKEN- PLEASE,  the  UserData  parameter  shall  contain 
an  integer  conforming  to  X.409  which  conveys  the 
priority. 

n)  The  receiving  RTS  can  use  the  value  of  the  Reason 
parameter  in  the  S-U- EXCEPTION-REPORT  to  suggest  to  the 
sending  RTS  that  it  should  either  interrupt  or  discard 
the  current  activity.  S-U- Exception  Reports  are  handled 
as  stated  in  Version  5  of  the  Implementors  Guide  pages 
12-13,  paragraph  E-33. 

o)  In  the  case  of  S-P-ABORT,  the  current  activity  (if  any) 
is  regarded  as  interrupted,   rather  than  discarded. 

p)  Table  7.12  illustrates  the  legal  negotiation 
possibilities  allowed  by  X.410  Clause  4.2.1  regarding 
checkpoint  size  and  window  size. 

q)  These  agreements  include  the  provisions  of  Version  6  of 
the  Implementors  Guide  identical  in  all  respects  to 
Version  5,  except  that  the  following  points  have  been 
added  to  section  3.5: 

for  section  4.4.1  of  X.410; 

"If  the  receiving  RTS  receives  an  S-ACTIVITY-DISCARD 
indication  primitive  and  has  already  issued  a  TRANSFER 
indication  primitive,  it  aborts  the  connection  (S-U-ABORT 
request)  with  the  "transfer  completed"  version  code." 

for  section  4.6.2  of  X.410 

"The  "transfer  completed  (7)"  abort  reason  is  used  to 
indicate  to  the  sending  RTS  that  the  receiving  RTS  could  not 
discard  the  activity  because  it  has  already  completed  the 
transfer  (issued  a  TRANSFER  indication  primitive)," 
Transfer  completed  (7)  is  also  added  to  the  table  of  abort 
reasons  in  this  section. 
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Table  7.12.     Checkpoint  window  size  of  IP 


acceptor  answer 

CS  =  0 
(or  unspecified) 
WS  unspecified 

CS  =  m 
WS  =  j 
(or  unspecified) 

CS  =  n 
WS  =  j 
(or  unspecified) 

initiator 
proposal 

CS  =  0 
(or  unspecified) 

WS  --=  i 
(or  unspecified) 

legal 

legal 

legal 

CS  =  k 
WS  =  1 
(or  unspecified) 

legal 

legal 

not  allowed 

Legend : 

o        CS  means  CheckpointSize 
o        WS  means  Windows ize 

o        i,  j,  k,  m,  and  n  are  integer  values  with  the  following 
relations : 


0  <  m  <  k  <  n  (values  assigned  to  CS) 

0  <  j  <  i  (values  assigned  to  WS) 


o        For  unspecified  parameters,   the  default  applies.     In  this 

case , the  numeric  relations  apply,   that  is,   the  default  values 
substitutefor  the  unspecified  integer. 

7.5.4.4  RTS  Protocol  Limitations 

The  RTS  Protocol  Limitations  for  this  profile  are  listed  in 
table  7.13. 
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Table  7.13.     RTS  protocol  elements 


Element  Class 

Restriction 

PConnect 

M 

M 

Value  =  0. 

pUserData 

M 

checkpoints  ize 

H 

windows  ize 

fl 

dialogueMode 

H 

ConnectionData 

M 

applicationProtocol 

G 

Value  =  1. 

H 

Value  =  8883. 

ConnectionData 

open 

G 

recover 

G 

open 

RTS  user  data 

G 

recover 

SessionConnectionldentif ier 

G 

Kio  user  cxaua 

mTAName 

G 

Maximum  length  32  characters 

password 

G 

Maximum  length  64  octets 

graphic  subset  of  IA5  only. 

<  null  RTS  User  Data  > 

G 

Generated  if  other  validation 

methods  are  used. 

SessionConnectionldentif ier 

CallingSSUserReference 

M 

Maximum  length  64  octets  including 

encoding  =  62  octets  of  T.61. 

CommonReference 

M 

AdditionalReference Information 

H 

Maximum  length  4  octets  including 

encoding  =  2  octets  of  T.61. 

PAccept 

G 

DataTransferSyntax 

M 

Value  =  0. 

pUserData 

M 

checkpoints ize 

H 

windows ize 

H 

ConnectionData 

M 

(Continued  on  next  page.) 
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Table  7.13.     RTS  protocol  elements,  continued 


Element 

Class 

Restriction 

PRefuse 

RefuseReason 

G 
M 

SS  User  Data 

(in  S- TOKEN -PLEASE) 

G 

See  Note 

Abortinf ormation 
(in  S-U-ABORT) 
AbortReason 
ref lectedParameter 

i  -■■  '  •  ■  G 

<'r-  H 

X 

Restricted  to  8  bits. 

End  of  Definitions 

Note:  Generated   if   supplied  by    the   RTS -user.       The   RTS   use  may 

specify  a  priority  in  the  TURN-PLEASE  primitive,  and  if  so, 
it  is  carried  as  the  SS-User-Data  in  S- TOKEN -PLEASE. 


7.5.5        Use  of  Session  Services 

The  session  requirements  and  use  of  session  are  covered  in 
section  5  of  this  document. 


7.5.6        Data  Transfer  Syntax 

This  section  defines  Presentation  Transfer  Syntax  and  notation 
rules  applicable  to  these  agreements.     Implementations  must 
conform  EXACTLY  as  specified  in  X.409  with  no  further 
restrictions.     Appendix  7C  defines  rendition  of  IA5  Text  and  T61 
characters . 


7.6     PRMD  to  ADMD  and  ADMD  to  ADMD 


7.6.1  Introduction 

This  section  defines  the  implementation  agreements  that  apply  to 
the  interface  between  two  management  domains  when  at  least  one  is 
an  ADMD.     A  message  arriving  at  an  ADMD  has  either  no  recipient 
within  that  domain  or  one  or  more  recipients  within  that  domain. 
In  the  former  case,  the  ADMD  serves  as  a  relay  between  two  or 
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more  domains  and  the  actions  required  of  that  ADMD  are 
independent  of  the  nature  (PRMD  or  ADMD)  of  the  domains.     In  the 
latter  case,  the  ADMD  is  responsible  for  delivering  messages  to 
the  proper  recipient(s)  within  its  jurisdiction,  and  may  also  be 
responsible  for  relaying  the  message. 

Given  the  two  roles  for  an  ADMD,  this  section  describes  two 
distinct  sets  of  functional  requirements  for  an  ADMD.     The  first 
is  the  relaying  requirement  that  is  needed  to  provide  PRMD  and 
other  ADMD  interworking .     The  second  is  analogous  to  the  PElMD's 
support  to  its  customers  through  the  integrated  UAs .     These  are 
distinct  functional  differences.     The  services  provided  to  the 
UAs  of  an  ADMD  are  independent  of  the  requirement  that  an  ADMD 
provide  a  function  for  interworking  with  any  type  of  Management 
Domain  (MD) .     Figure  7.5  illustrates  the  two  roles  played  by  an 
ADMD. 

This  section  is  presented  in  the  form  of  deviations  from  the 
agreements  applicable  to  PRMD-to-PRMD  (sec.   7.5).  Unless 
explicitly  noted  in  the  remainder  of  this  section,  all  of  the 
specifications  for  PEIMD  to  PRMD  apply  to  PRMD  to  ADMD  and  ADMD  to 
ADMD. 
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PRMD  or  ADMD 


IPM  -  UA 


<-- 
<  - 


MTA 


-P2- 
-Pi- 
ca) 


PRMD  or  ADMD 

PRMD  or  ADMD 

IPM  -  UA 

<-- 

-> 

IPM  -  UA 

MTA 

MTA 

PI 


PI 


(b) 


Figure  7.5.     An  ADMD  may  (b)  or  may  not  (a)  serve  as  a  relay. 


7.6.2        Additional  ADMD  Functionality 


The  following  defines  the  additional  ADMD  specific  functionality 
required  over  and  above  that  specified  in  the  PRMD  section. 

7.6.2.1  Relay  Responsibilities  of  an  ADMD 

ADMDs  will  relay  all  content  types  (not  just  P2)  unchanged 
in  the  absence  of  a  request  for  conversion. 
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7.6.2.2  PI  Protocol  Classification  Changes 

Table  7.14  describes  the  changes  to  the  PRMD  PI  Protocol 
classifications  required  for  a  delivering  Administration 
domain  (with  respect  to  the  original  message;   this  means  the 
domain  which  originates  the  delivery  reports) . 

Table  7.14.     PI  Protocol  Classification  Changes  for  a  Delivering  ADMD 


Protocol  Elements  Class 


Deliveredlnfo 
typeOfUA  H 

ReportedRecipientlnfo 
Supplementarylnformation  H      See  Note  1 

GlobalDomainldentif ier 
PrivateDomainldentif ier  H 


For  relaying  Administration  domains,  the  classifications  are  all  "X" 

For  originating  Administration  domains,   these  are  all 
"NOT  APPLICABLE." 


Note  1:     Domains  providing  access  to  TELEX/TELETEX  recipients,  whether 
directly  or  indirectly  as  a  result  of  bilateral  agreements 
between  domains,  must  ensure  that  this  information,  when 
present,  is  accessible  by  the  recipient  of  the  delivery  report. 


7.6.2.3  0/R  Names 

0/R  Names  shall  consist  of: 

o      CountryName , 

o      AdministrationDomainName . 

as  well  as  one  of  the  following: 

o      PrivateDomainName , 
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o  PersonalName , 

o  OrganizationName , 

o  OrganizationalUnit , 

o  UniqueUAIdentif ier , 

o  X12lAddress. 

and  permits  the  optional  inclusion  of  a 

o  DomainDef inedAttributeList . 

Note:      The  destination  PrivateDomainName  or 

OrganizationName  must  be  present  if  destined  for  a 
PEiMD.     The  ADMD  relaying  the  message  to  that 
destination  PRMD  requires  this  element. 

7. 6.2.4  PI  ADMD  Name 

Management  Domains  (MDs)  must  specify  in  the  ADMD  name  field 
of  the  0/R  Name  StandardAttributeList  in  PI,  the  name  of  the 
Administration  domain: 

o      to  which  the  message  is  being  sent  (in  recipient  names) 

o      from  which  the  message  originated  (in  the  originator 
name) , 


7.6.3        Interworking  with  Integrated  UAs 

If  the  message  originates  at  a  UA  owned  by  an  ADMD,  or  is 
delivered  to  such  a  UA,  the  0/R  Name  follows  the  same  Form  1 
Variant  1  constraints  as  the  base  specifications;  except  that  the 
ADMD  name  is  the  name  of  the  ADMD  that  owns  the  UA  and  instead  of 
supplying  a  PRMD  Name,  one  (or  more)  of  the  following  must  be 
provided: 

o  OrganizationName, 
o  OrganizationalUnit, 
o  PersonalName. 

and  may  optionally  include  a 

o      DomainDef inedAttributeList . 
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7.6.4        Differences  with  Other  Profiles 


7.6.4.1  TTC  Profile 

There  are  no  outstanding  issues  regarding  interworking 
between  TTC -conformant  systems  and  NIST-conformant  systems 
with  the  exception  of  the  number  of  recipients  and  the 
supported  MPDU  sizes.     The  Extensionldentif ier  field  may 
contain  a  maximiam  value  of  32K-1;  however,  according  to  the 
current  TTC  profile,   if  a  message  with  more  than  256 
recipients  is  received,  some  TTC -conformant  domain  may 
generate  a  nondelivery  notification.     This  also  applies  to 
the  ReportedRecipientlnfo  in  a  delivery  report.     Further,  a 
TTC  MTA  is  required  to  handle  an  MPDU  size  of  at  least  32KB. 
The  NIST  required  MPDU  size  is  2MB  as  covered  in  section 
7.5.3.3.     Other  differences  are  shown  in  Appendix  E.  TTC 
is  currently  based  on  Version  4  of  the  Implementor ' s  Guide. 

7.6.4.2  CEPT  Profile 
See  Appendix  7E. 

7.6.5        Connection  of  PRMDs  to  Multiple  ADMDs 

Given  that  Management  Domain  names  (both  PRMD  and  ADMD)  shall  be 
unique  within  the  U.S. ,   then  when  an  ADMD  is  presented  a  message 
for  transfer  from  a  PRMD,  it  will  accept  0/R  Names  (both 
originator  and  recipient)  which  have  an  AdministrationDomainName 
field  value  different  than  the  Administration's  name.  "Accept" 
implies  the  attempt  to  route/deliver  the  message  shall  be  made, 
as  appropriate,  based  upon  the  knowledge  that  MD  names  are 
unique . 

Whether  this  functionality  is  required  by  an  Administration  for 
conformance  to  this  agreement  is  for  further  study. 

If  a  PRMD  is  connected  to  two  or  more  ADMDs  which  are  not 
effectively  connected  (either  directly  or  via  a  third  ADMD) ,  full 
X.400  functionality  shall  not  be  available.     Problems  occur 
especially  in  the  areas  of: 

o      Naming , 
o  Routing, 
o  Replying. 

It  should  be  noted  that  a  single  PRMD  that  is  connected  to  more 
than  one  ADMD  can  be  represented  by  more  than  one  combination  of 
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country-name,  ADMD-name,  and  PRMD  name.     For  example,   it  may 
occur  that  the  PRMD-name  for  a  particular  PRMD  may  take  different 
values,   depending  on  the  ADMD-name.     Implementors  should  be  aware 
of  the  consequences  of  these  possibilities  on  routing. 

7.6.6  Connection  of  an  ADMD  to  a  Routing  PRMD 

It  is  possible  for  a  collection  of  interconnected  private  domains 
to  establish  one  domain  as  the  "gateway"  to  an  ADMD,  and  hence  to 
the  world. 

If  an  ADMD  is  connected  to  such  a  gateway  PRMD,   the  individual 
private  domains  shall  be  registered  with  the  Administration. 
Administrations  need  not  support  such  connections. 

Note  also  that  upon  receipt  by  the  ADMD  of  a  message  originating 
somewhere  within  the  PRMD  collection,   that  the  Traceinf ormation 
may  contain  more  than  one  element. 

The  X.400  Recommendations  specify  that  an  ADMD  should  not  attempt 
to  relay  a  message  destined  for  another  ADMD  through  a  PRMD,  thus 
an  ADMD  should  ensure  that  messages  destined  for  another  ADMD  are 
not  relayed  through  a  PRMD.     It  should  be  noted,  however,   that  a 
relaying  PRMD  will  relay  any  such  message  it  receives. 

7.6.7  Management  Domain  Names 

o        All  Management  Domain  Names  (both  Private  and 

Administration)  shall  be  unique  within  the  U.S. 

o        A  central  naming  authority  shall  be  established  to  register 
domain  names . 


7.6.8        Envelope  Validation  Errors 

For  validation  errors,   a  non-delivery  notice  shall  be  generated 
(if  possible)  with  reason  code  of  ' unableToTransf er '  and 
diagnostic  code  of  ' invalidParameters '   (unless  specified 
otherwise) . 

ADMDs  will  validate  Pi  Envelopes  in  the  following  areas: 

a)  The  X.409  syntax  of  all  elements  should  be  checked. 

b)  The  pragmatic  constraint  limits  (lengths  of  fields  and 
number  of  occurrences  of  fields)  should  be  checked. 
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Semantic  validation  of  the  following  elements  should  be 
done : 

o      originator  0/R  Name , 

o      recipient  0/R  Name  in  the  Recipientinf o , 
o  Priority. 

Only  recipient  Names  with  the  responsibility  flag  set  should 
be  validated.     The  validation  of  0/R  names  is  defined  in 
7.8.3.3;  the  validation  of  priority  is  defined  in  7.8.3.7.1. 

MPDU  Identifier  Validation 

o      Validation  of  the  GlobalDomainldentif ier  component  of 
the  MPDU  Identifier  is  performed  upon  reception  of  a 
message  (i.e.,  as  a  result  of  a  TEIANSFER.  Indication)  . 

o      The  country  name  should  be  known  to  the  validating 

domain,  and  depending  on  the  country  name,  validation  of 
the  ADMD  name  may  also  be  possible. 

o      Additional  validation  of  the  GlobalDomainldentif ier  is 
performed  against  the  corresponding  first  entry  in  the 
Tracelnformation.     If  inconsistencies  are  found  during 
the  comparison,  a  non-delivery  notice  with  the  above 
defined  reason  and  diagnostic  codes  is  generated. 

o      A  request  will  be  generated  to  the  CCITT  for  a  more 
meaningful  diagnostic  code  (such  as 
' InconsistentMPDUIdentif ier ' ) . 

9        Quality  of  Service 

7.6.9.1  Domain  Availability 

7.6.9.1.1      ADMD  Availability 

The  goal  is  to  provide  24  hour  per  day  availability. 
Note  that  there  will  be  periods  of  time  when  an  ADMD  may 
be  unavailable  due  to  maintenance  windows  in  its 
supporting  network  or  in  an  MTA  within  the  domain. 
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7.6.9.1.2      PRMD  Availability 

Although  the  goal  of  PRMD  availability  is  also  24  hours 
per  day,  business  reasons  are  likely  to  dictate  some 
different  level  of  availability.     ADMDs  shall  require  a 
profile  from  the  PRMD  that  indicates  its  schedule  of 
regular  availability  to  the  ADMD. 

7.6.9.2  Delivery  Times 

In  the  absence  of  standardized  quality  of  service 
parameters,   the  following  are  agreed  to.     When  standardized 
parameters  from  CCITT  Study  Group  I  become  available,  they 
shall  be  adopted. 
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a)     In  table  7.15 

the  following  delivery  time  targets  are 

established: 

Table  7.15. 

Delivery  Time  Targets 

Delivery  Class 

95%  Delivered  Before 

Urgent 

3/4  hour 

Normal 

4  hours 

Non-Urgent 

24  hours 

b)     The  interval(s)  between  retries  and  the  number  of  retry 
attempts  that  an  ADMD  uses  in  attempting  delivery  to  a 
PRMD  or  integrated  UA,  will  be  locally  determined  domain 
parameters.     However,   the  total  elapsed  times  after 
which  delivery  attempts  will  be  stopped  are  shown  in 
table  7.16.     This  implies  that,  after  these  times,  a 
Non-Delivery  Notice  will  be  generated. 

An  Administration  shall  continue  to  attempt  delivery 
until  the  forced  nondelivery  time,  even  if  the  recipient 
domain  has  scheduled  an  unavailability  window. 

Table  7.16.     Forced  Nondelivery  Times 


Delivery  Class 

NonDelivery  Forced  After 

Urgent 

4  hours 

Normal 

24  hours 

Non-Urgent 

36  hours 

Note:        Both  tables  apply  to  the  period  between  acceptance  by 
the  originating  MTA  in  the  originating  Administration 
domain  to  the  time  of  delivery  in  the  destination 
Administration  domain.     Transit  time  within  PRMDs  is  NOT 
included  in  the  above  times. 


7.6.10      Rill ing  Information 

a)      All  aspects  relating  to  billing,  charging,  tariffs, 
settlement,  and  in  particular  to  the  use  of  the 
billinglnformation  field  in  the  delivery  report,  is  subject 
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to  bilateral  agreement,  and  shall  not  be  addressed  in  these 
implementation  agreements. 

b)      No  ADMD  shall  require  a  PRMD  to  supply  or  process  billing 
information. 


7.6.11  Transparency 

a)     No  PI  extensions,  other  than  the  MOTIS  extensions  are  to 
be  allowed  (Reference  A/3211).     Should  an  ADMD  receive  a 
message  containing  PI  extensions,   it  shall  generate  a 
non-delivery  notice  (if  possible)  with  reason  code  of 
unableToTransfer  and  diagnostic  code  of 
invalidParameters . 


If  MOTIS  elements  are  present,  a  relaying  MTA  can  optionally: 

o      Relay  the  message.     If  the  MTA  does  relay,   it  must  not 
drop  any  of  the  protocol  elements. 


o      Non-Deliver  the  message. 
A  receiving  MTA  can  optionally: 
o      Deliver  the  message 
o      Non-Deliver  the  message. 


b)  The  CCITT  has  been  requested  to  establish  a  more  meaningful 
diagnostic  code  (such  as  protocolError)  for  this  occurrence. 
Such  a  code  has  now  been  provided  in  the  Implementors  Guide. 

c)  P2  extensions  shall  be  relayed  transparently  by  ADMDs . 


7.6.12      RTS  Password  Management 

RTS  password  management  shall  be  a  local  matter.     This  includes: 

o      password  length 

o      frequency  of  changes 

o      exchange  of  passwords  with  communicating  partners 
o      loading  passwords  (  i.e.,  the  timing  of  password  changes 
with  respect  to  active  associations) . 
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7.6.13 


For  Further  Study 


Issues  requiring  further  study  are: 


o 


o 


Intra-Domain  Routing 
Multi-Vendor  Domains 


7.7     INTER  and  INTRA  PRMD  CONNECTIONS 


7.7.1 


Introduction 


This  section  is  limited  in  scope  to  issues  arising  from  the 
indirect  connection  of  a  PRMD  to  another  PRMD  or  to  an  ADMD,  and 
to  the  interconnection  of  MTAs  to  form  inter-PRMD  connections. 
Indirect  means  that  the  connection  is  made  via  a  relaying  PRMD. 
The  X.400  Recommendations  describe  the  way  that  a  PRMD  connects 
to  a  ADMD  and  the  way  that  an  ADMD  connects  to  another  ADMD.  The 
Recommendations  do  not,  however,  describe  the  way  that  a  PRMD 
connects  indirectly  to  an  ADMD  or  another  PRMD,  nor  do  they 
describe  the  way  that  MTAs  are  connected  within  a  PRMD.  These 
configurations  (shown  in  figs.  7.6  and  7.7)  are  useful,  for 
example,   in  connecting  equipment  from  different  vendors  at  a 
single  customer  site. 

The  PI  protocol  and  its  related  services  for  both  inter  and  intra 
PRMD  connections  are  addressed  in  this  section.     In  addition,  a 
method  for  routing  within  a  PRMD  is  given.     It  is  recognized  that 
uniform  methods  for  Administration,  maintenance,  and  quality  of 
service  should  be  developed  for  such  configurations,  and  this 
work  is  for  further  study. 

This  section  describes  the  minimum  that  must  be  provided  in  order 
to  implement  a  relaying  PRMD  and  a  MTA  within  a  PRMD. 

This  section  is  presented  in  the  form  of  deviations  from 
agreements  applicable  to  PRMD  to  PRMD  connection  (sec.  7.5). 
That  is,  unless  specifically  noted  in  the  remainder  of  this 
section,   the  agreements  in  section  7.5  apply  to  both  relaying 
PRMDs  and  MTAs  within  a  PRMD. 

It  should  be  noted  that  the  comments  regarding  ORNames  in  section 
7.6.5  also  apply  to  this  section. 
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7.7.2        The  Relaying  PRMD 

A  PRMD  that  has  the  capability  of  relaying  messages  to  another 
PRMD  is  called  a  relaying  PRMD.     A  PRMD  implementation  need  not 
claim  to  be  a  relaying  PRMD.     A  PRMD  implementation  which  does 
claim  to  be  a  relaying  PRMD  must  follow  the  implementation 
agreements  in  this  section. 


7.7.2.1  Relay  Responsibilities  of  a  PRMD 

The  responsibilities  of  a  relaying  PRMD  are  the  same  as 
those  of  an  ADMD  (as  specified  in  sees.   7.6.8  and  7.6.2.1). 
In  addition,  the  PRMD  will  simply  deliver  messages  routed  to 
it  from  an  ADMD,  even  if  this  results  in  routing  a  message 
from  the  ADMD  to  the  PRMD  to  another  ADMD, 


7.7.2.2  Interaction  with  an  ADMD 

In  order  for  an  ADMD  to  route  a  message  to  ADMD  A  via  ADMD 
B,   it  must  know  that  A  is  reachable  through  B.  Similarly, 
in  order  for  any  MD  to  route  a  message  to  PRMD  A  via  a 
relaying  PRMD  B,   it  must  know  that  A  is  reachable  through  B 
(see  fig.  7.8). 


ADMD 

PRMD  A 

PRMD  B 

PRMD  C 

Relay 

Figure  7.6.     Relaying  PRMD. 
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PRMD 


MTA 

A 

MTA 

B  - 

MTA  D 


MTA  C 


ADMD 

or 
PRMD 


Figure  7.7.     Intra  PRMD  connections. 


Note  1:  Section  7.6.6  specifies  that  ADMDs  are  not  required  to 
connect  to  a  relaying  PRMD,  but  they  are  not  precluded 
from  doing  so. 

Note  2:     Tracelnformation  may  have  more  than  one  sequence  on 

submission  of  a  message  by  a  relaying  PRMD  to  an  ADMD. 


MD  D 


relay 

MD    C  with 
a  message 
for  A 


relay 
MD  B 

MD  A 

Figure  7.8,     MD  C  must  know  of  A  to  route  the  message. 


7.7.3        Intra  PRMD  Connections 

A  PRMD  is  composed  of  MTAs  which  cooperate  to  perform  the 
functions  expected  of  a  domain.     An  MTA  implementation  need  not 
claim  to  follow  the  implementation  agreements  of  this  section. 


7.7.3.1  Relay  Responsibilities  of  an  MTA 

The  relaying  responsibilities  of  an  MTA  are  the  same  as 
those  of  an  ADMD  (as  specified  in  sees.  7.6.8  and  7.6.2.1) 
with  one  exception:  loop  suppression  within  the  domain 
is  done  using  the  MOTIS  InternalTracelnfo  protocol 
element.     The  MTA  must  validate  the  InternalTracelnfo  (see 
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sec.   7.8.3.5  for  details  on  validation).     In  addition,  the 
PRMD  will  simply  deliver  messages  routed  to  it  from  an 
ADMD,  even  if  this  results  in  routing  a  message  from  the 
ADMD  to  the  PRMD  to  another  ADMD  (please  see  sec.  7.6.6). 


7.7.3.2  Loop  Suppression  within  a  PRMD 

a)     The  only  mechanism  defined  in  the  X.400  Recommendations 
for  suppressing  loops  is  Traceinf ormation,  which  is 
added  on  a  per  domain  basis  to  detect  and  suppress  loops 
among  domains.     Loops  among  MTAs  within  a  domain  need  to 
be  detected  and  suppressed.     This  implies  that  each  MTA 
must  add  trace  information  that  is  meaningful  within  the 
domain.     The  MOTIS  solution  of  adding  InternalTracelnfo 
to  the  PI  Envelope  of  a  message  was  adopted.  The 
definition  of  InternalTracelnfo  is  given  in  figure  7.9. 
The  InternalTracelnfo  is  added  by  each  MTA  within  a  PRMD 
to  handle  a  message,  and  it  is  examined  in  the  same  way 
as  Traceinf ormation  to  detect  and  suppress  loops. 


InternalTracelnfo  : :=  [APPLICATION  30] 
IMPLICIT  SEQUENCE  OF 
SEQUENCE  { 
MTAName , 

MTASuppliedlnfo  ) 
MTAName  : :=  PrintableString 


Figure  7.9.     Definition  of  InternalTracelnfo. 

If  the  MTAName  and  password  of  X.411  are  used  for 
validation,     then  it  is  recommended  that  the  MTAName 
used  for  validation  also    be  used  in  the 
InternalTracelnfo.     However,   there  is  a  complication:  in 
X.411,  MTAName  is  an  lASString,   and  the  MTAname  defined 
by  MOTIS  is  a  PrintableString.     Efforts  will  be  made  to 
change  the  MOTIS  definition  from  PrintableString  to 
IA5String. 

b)     Three  actions  are  defined  in  MTASuppliedlnfo:  relayed, 
rerouted,  and  recipientReassignment  as  shown  in  figure 
7.10.     The  recipientReassignment  action  is  not  supported 
in  these  agreements.     The  ability  to  generate  it  is  not 
required,  and  if  it  is  present  on  an  incoming  message, 
the  action  field  will  be  ignored. 
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MTASuppliedlnfo  : :=  SET  { 
arrival  [0]  IMPLICIT  Time, 
deferred  [1]  IMPLICIT  Time  OPTIONAL, 
action  [2]  IMPLICIT  INTEGER 

{  relayed(O) ,  rerouted(l),  recipientReassignment (2)  } 
previous  MTAName  OPTIONAL  ) 


Figure  7.10.     Defined  Actions  in  MTASuppliedlnfo. 
7.7.3.3  Routing  Within  a  PRMD 

a)  Routing  within  a  PRMD  is  complicated  by  the  lack  of  a 
directory  standard.     In  particular,   it  constrains 
intra-domain  routing  decisions  to  be  based  on  some 
combination  of  the  intra-domain  attributes  of  the  0/R 
Name,  Organization  Name  Organizational  Units,  and 
Personal  Name.     In  order  to  enhance  interworking  and  to 
reduce  the  difficulty  of  configuring  intra-domain 
connections,  it  is  useful  to  restrict  the  ways  in  which 
these  may  be  used  in  making  routing  decisions. 

b)  However,  it  is  recognized  that  vendors  may  wish  to 
provide  MTAs  with  varying  degrees  of  routing  capability 
within  a  PRMD  as  a  temporary  expedient  until  appropriate 
standards  for  automated  construction  of  directories  and 
routing  tables  are  available.     This  section  assigns 
class  numbers  to  certain  levels  of  routing  capability 
and  discusses  the  consequences  of  using  MTAs  which  fall 
into  each  class.     The  classification  scheme  will  allow 
some  diversity  in  allocating  O/R  Name  space  and  in 
configuring  intra-domain  routes. 

c)  When  other  methods  are  recommended  by  standards  bodies, 
the  classification  scheme  described  here  will  become 
obsolete.     Large-scale,  multi-vendor  PElMDs  may  not  be 
practical  in  the  absence  of  standardized  methods. 

7.7.3.3.1      Class  Designations 

When  it  is  clear  that  a  message  is  to  be  delivered 
within  a  domain,   the  Country  Name,  ADMD  Name,   and  PRMD 
Name  have  already  served  their  purpose  in  determining 
the  next  MTA  in  the  route  to  the  recipient.  The 
remaining  fields  that  might  be  used  on  making  routing 
decisions  within  the  PRMD  are  the  Organization  Name, 
Organizational  Units,  and  Personal  Name. 
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MTAs  are  classified  by  their  ability  to  discriminate 
between  0/R  names  when  making  routing  decisions  within  a 
PRMD.     Conformant  MTAs  will  be  classified  as  shown  in 
table  7.17. 

Table  7.17.     Conformant  MTA  Classifications 


Class  1 

Class  2 

Class  3 

Organization  Name 

H 

H 

H 

SEQUENCE  OF  Organizational  Unit 

X 

H 

H 

Personal  Name 

X 

X 

H 

a)     An  'H'  means  that  the  MTA  must  be  able  to  base  its 

intra-domain  routing  decisions  on  the  given  component  of 
the  O/R  Name.     In  particular,  both  Class  2  and  Class  3 
MTAs  must  be  able  to  discriminate  on  all  the  members  in 
a  supplied  sequence  of  OrganizationalUnits .     A  Class  3 
MTA  must  be  able  to  discriminate  on  all  of  the  elements 
in  a  PersonalName . 

An  'X'  means  that  the  MTA  need  not  have  the  ability  to 
discriminate  on  the  given  component. 

b)  There  is  a  hierarchy  in  support  of  components.  The 
ability  to  discriminate  on  a  given  component  does 
not  imply  the  requirement  to  do  so:  e.g.,  a  Class  3 
MTA  is  not  required  to  have  tables  for  every 
PersonalName  in  the  domain.     Equally,   an  MTA  which 
can  discriminate  on  OrganizationalUnits  to  make 
routing  decisions  need  not  always  use  the  full 
sequence  in  an  O/R  Name  if  a  partial  sequence 
provides  enough  information. 

c)  The  above  classifications  only  apply  to  routing 
decisions  in  selecting  a  next  hop  within  a  domain. 
All  MTAs  are  entitled  to  examine  the  full  O/R  Name 
when  identifying  their  own  directly  served  UAs . 

d)  The  routing  table  of  a  Class  1  MTA  will  be 
relatively  small,  because  intra-domain  routing 
decisions  are  based  solely  on  OrganizationName .  The 
routing  table  of  a  Class  2  MTA  may  be  substantially 
larger  and  more  complex  because  of  its  ability  to 
discriminate  on  OrganizationalUnits  as  well  as 
OrganizationName  to  make  routing  decisions.  The 
routing  table  of  a  Class  3  MTA  may  be  larger  still. 
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because  its  use  of  the  components  of  PersonalName  in 
addition  to  the  other  information. 


7. 7. 3.3.2      Specification  of  MTA  Classes 

If  an  MTA  implementation  claims  to  follow  the 
implementation  agreements,   it  must  be  either  a  Class  1, 
Class  2,  or  a  Class  3  MTA.     The  class  of  an  MTA 
implementation  should  be  specified  so  that  PRMD 
administrators  can  choose  equipment  properly. 


7.7.3.3.3      Consequences  of  Using  Certain  Classes  of 
MTAs 

Definition:  An  MTA  which  accepts  submission  requests  and 
furnishes  delivery  indications  to  a  UA  is 
said  to  "directly  serve"  the  UA. 

a)     The  presence  in  a  domain  of  an  MTA  acting  as  a  Class 
1  or  Class  2  MTA  imposes  administrative  restrictions 
on  the  assignment  of  0/R  Names  to  UAs  and  in  the 
configuration  of  routes  within  that  domain. 

o      A  Class  1  MTA  may  directly  serve  UAs  from 

several  OrganizationNames .  However,   if  a  Class  1 
MTA  directly  serves  a  UA  with  a  given 
OrganizationName ,  no  other  MTA  in  the  domain  may 
directly  serve  a  user  with  the  same 
OrganizationName.     This  means  that  if  all  MTAs 
in  a  domain  are  Class  1,   then  all  UAs  with  a 
given  OrganizationName  must  be  assigned  to  the 
same  MTA. 

o      A  Class  2  MTA  may  directly  serve  UAs  from  any 
combination  of  OrganizationName  and  sequence  of 
OrganizationalUnits .     However,   if  a  Class  2  MTA 
directly  serves  a  UA  with  a  given  combination, 
no  other  MTA  in  the  domain  may  directly  serve  a 
user  with  the  same  combination.     This  means  that 
if  all  MTAs  in  a  domain  are  Class  2,   then  all 
UAs  with  a  given  OrganizationName  and  sequence 
of  OrganizationalUnits  must  be  assigned  to  the 
same  MTA. 

o      A  domain  consisting  entirely  of  Class  3  MTAs  is 
free  of  all  the  above  restrictions. 


7-49 


December  ' 89 


b)     If  Class  1  or  Class  2  MTAs  are  used  to  perform 
relaying  within  a  PRMD  containing  MTAs  of  other 
classes,  care  must  be  exercised  in  determining  the 
topology  of  the  domain  to  avoid  leaving  certain  UAs 
inacessible  from  certain  MTAs  within  the  domain. 
The  example  below  shows  one  of  the  configurations 
that  should  be  avoided.     The  example  is  intended  to 
stimulate  careful  examination  of  the  relationship 
between  network  and  organizational  topologies. 


MTA  A 
serving 
Organization  X 


MTA  B 


(Class  1) 


MTA  C 
serving 
Organization  X 


Figure  7.11.     Example  of  a  configuration  to  be  avoided. 


In  figure  7.11,  B  will  route  all  messages  for 
Organization  X  to  either  A  or  C  because  B  is  a  Class  1 
MTA.     The  administrator  who  created  this  configuration 
probably  wanted  B  to  route  some  messages  for 
Organization  X  to  A,  and  some  to  C.     However,  B  does  not 
have  the  capability  for  this  because  it  is  only  a  Class 
1  MTA.     The  configuration  in  figure  7.11  can  be 
corrected  by  replacing  B  with  a  Class  2  or  Class  3  MTA. 


7.7.3.4  Uniqueness  of  MPDUidentif iers  Within  a  PRMD 

When  generating  an  lASString  in  an  MPDUidentif ier ,  each  MTA 
in  a  domain  must  ensure  that  the  string  is  unique  within  the 
domain.     This  shall  be  done  by  providing  an  MTA  designator 
with  a  length  of  12  octets  which  is  unique  within  the 
domain,   to  be  concatenated  to  a  per  message  string  with 
maximum  length  of  20  octets. 

Two  pieces  of  information,   the  MTA  name  and  MTA  designator, 
need  to  be  registered  within  a  PRMD  to  guarantee  uniqueness. 
This  registration  facility  need  not  be  automated.     If  the 
MTA  name  is  less  than  or  equal  to  12  characters,   it  is 
recommended  that  it  also  be  used  as  the  MTA  designator. 
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1 .1  .l\        Service  Elements  and  Optional  User  Facilities 

A  PRMD  made  up  of  MTAs  which  support  varying  sets  of  service 
elements  in  addition  to  those  required  in  these  agreements  may 
appear  to  provide  inconsistent  service  for  these  elements.  For 
example,  if  one  MTA  supports  deferred  delivery  and  another  MTA 
does  not,   then  deferred  delivery  can  be  used  by  some,  but  not 
all,  users  in  the  PRMD.     Similarly,   if  one  MTA  supports  return  of 
contents  and  another  does  not,   then  a  user  outside  of  the  PRMD 
will  receive  returned  contents  for  messages  sent  to  one  user,  but 
not  for  messages  sent  to  another  user.     Note  that  this  same 
inconsistency  occurs  when  sending  to  two  PRMDs  which  support 
different  additional  optional  elements. 

7.7.5        X.400  Protocol  Definitions 

This  section  describes  additions  and  modifications  to  section 
7.5.3  which  are  required  for  implementation  of  a  relaying  PRMD  or 
an  MTA  within  a  PRMD. 


7.7.5.1  Protocol  Classification 

a)  The  classification  scheme  given  in  section  7.5.3.1 
applies  to  elements  passing  from  one  PRMD  to  another. 
For  both  relaying  PRMDs,  and  MTAs  in  a  PRMD,   the  same 
classification  scheme  will  be  used,  but  within  a  PRMD 
the  classification  applies  to  elements  passing  from  one 
MTA  to  another. 

b)  In  addition  to  the  classifications  given  in  section 
7.5.3.1,  a  classification  of  Prohibited  has  been  used. 

PROHIBITED  =  P 

This  element  shall  not  be  used.     Presence  of  this 
element  is  a  protocol  violation. 

7.7.5.2  PI  Protocol  Elements 

Table  7.18  contains  protocol  elements  and  their  classes.  An 
*  signifies  that  the  classification  of  the  protocol  element 
has  not  changed  from  table  7.8. 
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Table  7.18.     PI  Protocol  Elements 


Element 

Class 

Restrictions  and  Comments 

UMPDUEnvelope 
MPDUIdentifier 

M* 

This  field  needs  to  be  unique 
within  a  PRMD.     See  section 
7.7.3.4  for  the  method  of 
ensuring  uniqueness . 

originator 

M* 

It  is  recommended  that  all 
components  of  the  originator's 
ORName  be  included  to  help  ensure 
that  reports  can  be  returned. 

Traceinf ormation 

M* 

The  first  MTA  in  the  domain  to 
receive  the  message  adds  the 
Traceinf ormation.  Subsequent 
MTAs  can  update  the 
Tracelnformation  in  the  event  of 
conversion  or  deferred  delivery. 
When  a  message  is  generated,  the 
originating  MTA  adds  the 
Tracelnformation . 

InternalTracelnfo 

M/P 

This  element  is  mandatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
Elements  are  always  added  to  the 
end  of  the  sequence.     (See  Note  1) 

InternalTracelnfo 
MTAName 

M 

MTANames  within  a  PRMD  must  be 
unique.     See  section  7.7.3.4  for 
the  method  of  assuring  uniqueness 
Maximum  length  =  32  characters. 

MTASuppliedlnfo 

M 

(Continued  on  next  page.) 
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Table  7.18.       PI  Protocol  Elements,  continued 


Element 

Class 

Restrictions  and  Comments 

MTASuppliedInf o 

arrival 

M 

deferred 

X 

This  field  must  be  generated  by 

MTAs  which  perform  deferred 

delivery . 

action 

M 

See  section  7.7.3.2  for 

TP Q t"T  1  p t"  1  on c:   on  vpliipc;   of   t"b  1 

field. 

previous 

X 

This  field  must  be  generated  by 

MTAs  which  perform  rerouting. 

DeliveryReportEnvelope 

Tracelnformation 

M* 

The  first  MTA  in  the  domain  to 

receive  the  report  adds  the 

Tracelnformation.     When  a  report 

is  generated,   the  originating  MTA 

adds  the  Tracelnformation. 

InternalTracelnfo 

M/P 

This  field  is  mandatory  for 

envelopes  transferred  between 

MTAs  within  a  PRMD ,  and 

prohibited  in  messages 

transferred  outside  the  domain. 

(See  Note  1) 

De 1 iveryRepor tContent 

intermediate  InternalTracelnfo 

P 

If  it  were  possible  to  include 

this  field  in  the  delivery  report 

content,  an  audit  and  confirmed 

report  could  be  provided  to 

detect  problems  within  a  PRMD. 

Efforts  are  being  made  to  add 

this  field  to  the  MOTIS 

definition. 

Deliveredlnfo 

typeOFUA 

R* 

It  is  the  responsibility  of  the 

MTA  generating  the  report  to 

generate  this  element. 

(Continued  on  next  page.) 
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Table  7.18.     PI  Protocol  Elements,  continued 


Element 

Class 

Restrictions  and  Comments 

ProbeEnvelope 

Tracelnformation 

M* 

The  first  MTA  in  the  domain  to 
receive  the  probe  adds  the 
Tracelnformation.     When  a  probe 
is  generated,  the  originating  MTA 

adds  the  Tracelnformation. 

InternalTracelnfo 

M/P 

This  field  is  mandatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
(See  Note  1) 

Note  1: 

The  M  classification  is  only  applicable  if  an 
implementation  is  claiming  conformance  according  to 
section  7.10.2,  point  (g)  4th  bullet. 

7.7.5.3 

Reliable  Transfer 

Server  CRTS) 

In  the  pUserData  of  PConnect,   the  value  of 
applicationProtocol  should  be  1.     This  value  was  chosen 
because  the  agreements  on  intra- domain  connections  are  not 
strictly  PI,  nor  are  they  MOTIS.     Philosophically,   it  would 
be  good  to  choose  a  new  application  protocol  identifier  for 
these  agreements,  but  this  introduces  too  many  practical 
problems.     Since  these  agreements  are  closer  to  PI  than  to 
MOTIS,   the  value  of  1  will  be  used.     This  will  not  cause 
(  interworking  problems  between  domains,  because  the  only 

deviation  from  PI  is  the  InternalTracelnfo,  which  will  not 
be  present  in  messages  transferred  outside  of  a  domain. 

7.8     ERROR  HANDLING 


;     This  section  describes  appropriate  actions  to  be  taken  upon  receipt  of 
protocol  elements  which  are  not  supported  in  this  profile,  malformed 
MPDUs,  unrecognized  0/R  Name     forms,  content  errors,  errors  in 
reports,  and  unexpected  values  for  protocol  elements. 


7-54 


December  '89 


7.8.1  MPDU  Encoding 

The  MPDU  should  have  a  context-specific  tag  of  0,   1,  or  2.     If  it 
does  not  have  one  of  these  tags,  it  is  not  possible  to  figure  out 
who  originated  the  message.     Therefore,  the  way  this  error  is 
reported  is  a  local  matter. 

7.8.2  Contents 

Once  delivery  to  the  UA  has  occurred,   it  is  not  possible  to 
report  errors  in  P2  information  to  the  originator.     In  addition, 
it  seems  unreasonable  to  insist  that  the  MTA  that  delivers  a 
message  ensure  that  the  P2  content  of  the  message  is  acceptable. 
As  a  result,  the  handling  of  content  errors  is  a  local  matter. 

7.8.3  Envelope 

This  section  describes  the  handling  of  errors  in  message 
envelopes.     Some  of  the  error  conditions  described  below  may  be 
detected  in  a  recipient's  0/R  Name.     This  may  limit  the  reporting 
MTA's  ability  to  generate  a  nondelivery  notification  that 
accurately  reflects  the  erroneous  0/R  Name  in  the 
ReportedRecipientInf o .     This  handling  of  this  situation  is  a 
local  matter. 


7.8.3.1  Pragmatic  Constraint  Violations 

In  all  cases  of  pragmatic  constraint  violation,  a 
nondelivery  report  should  be  generated  with  a  ReasonCode  of 
unableToTransf er ,  and  a  Diagnos ticCode  of 
pragmaticCons traintViolat ion . 

7.8.3.2  Protocol  Violations 

a)  If  all  required  protocol  elements  are  not  present,  a 
nondelivery  report  with  a  ReasonCode  of  unableToTransfer 
and  a  DiagnosticCode  of  protocolViolation  should  be 
generated. 

b)  If  a  protocol  element  is  expected  to  be  of  one  type,  but 
is  encoded  as  another,  then  a  nondelivery  report  with  a 
ReasonCode  of  unableToTransfer  and  a  DiagnosticCode  of 
invalidParameters  should  be  generated. 
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7.8.3.3  0/R  Names 

a)  The  domain  that  has  responsibility  for  delivering  a 
message  should  also  have  the  responsibility  to  send  the 
nondelivery  notification  if  the  message  cannot  be 
delivered.     Therefore,  each  MTA  should  only  validate  the 
0/R  Names  of  recipients  with  responsibility  flags  set  to 
TRUE.     In  addition,  a  nondelivery  notification  can  only 
be  sent  if  the  originator's  0/R  Name  is  valid. 

b)  If  any  element  in  the  0/R  Name  is  unrecognized  or  if  the 
CountryName ,  AdministrationDomainName ,  and  one 

of PrivateDomainName  and  OrganizationName  (and,  for 
ADMDs,  PersonalName  and  OrganizationalUnit)  are  not  all 
present,   then  a  nondelivery  report  should  be  generated 
with  a  ReasonCode  of  unableToTransf er ,  and  a 
DiagnosticCode  of  unrecognizedORName .     If  the  message 
can  be  delivered  even  though  the  ORName  is  invalid, 
delivery  is  a  local  matter.     Note,  however,   that  if  the 
message  is  delivered,   the  invalid  ORName  might  be 
propagated  through  the  X.400  system  (e.g.,  by 
forwarding) . 

c)  If  the  0/R  Name  has  all  of  the  appropriate  protocol 
elements  and  the  message  still  cannot  be  delivered  to 
the  recipient,   the  following  DiagnosticCodes  may  appear 
in  the  nondelivery  report: 

unrecognizedORName , arabiguousORName , and  uaUnavailable . 

7.8.3.4  Tracelnformation 

a)  Since  non-relaying  domains  need  not  do  loop  suppression, 
domains  with  responsibility  for  delivering  the  message 
need  not  be  concerned  about  the  semantics  of  the 
Tracelnformation,   that  is,  arrival  time  and  converted 
EncodedlnformationTypes  can  be  provided  to  the  UA 
without  inspection  by  the  MTAs  of  the  domain  as  long  as 
the  Tracelnformation  is  properly  encoded  according  to 
X.409. 

b)  When  a  message  is  accepted  for  relay,   the  relaying 
domain  must  check  that  a  Tracelnformation  SEQUENCE  has 
been  added  by  the  domain  that  last  handled  the  message. 
If  the  appropriate  Tracelnformation  was  not  added,  this 
should  be  treated  as  a  protocolViolation  (sec. 
7.8.3.2). 

c)  In  addition,   the  relaying  domain  must  check  that  the 
information  was  added  in  the  sequence  defined  by  the 
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rules  for  adding  Tracelnformation  in  the  CCITT  X.400 
Implementor ' s  Guide.     If  the  sequence  is  invalid, then  a 
nondelivery  report  should  be  generated  with  a  ReasonCode 
of  unableToTransfer  and  a  diagnosticCode  of 
invalidParameters . 

Note:  It  would  be  desirable  for  the  CCITT  to  add  a 
diagnostic  code  of  invalidTracelnformation  to 
allow  a  more  meaningful  description  of  this 
problem.  A  request  for  this  new  diagnostic  code 
will  be  submitted. 


7.8.3.5  InternalTracelnfo 

This  section  applies  only  to  MTAs  which  follow  the 
agreements  of  section  7.7. 

a)  When  a  message  is  accepted  for  relay  from  another  MTA  in 
the  domain,   the  relaying  MTA  must  check  that  an 
InternalTracelnfo  SEQUENCE  has  been  added  by  the  MTA 
that  last  handled  the  message.     If  the  appropriate 
InternalTracelnfo  was  not  added,  this  should  be  treated 
as  a  protocolViolation  (sec.  7.8.3.2). 

b)  In  addition,  the  relaying  MTA  must  check  that  the 
information  was  added  in  the  sequence  defined  by  the 
rules  for  adding  Tracelnformation  in  the  CCITT  X.400 
Implementor ' s  Guide.     If  the  sequence  is  invalid,   then  a 
nondelivery  report  should  be  generated  with  a  ReasonCode 
of  unableToTransfer  and  a  diagnosticCode  of 
invalidParameters . 

Note:  It  would  be  desirable  for  the  CCITT  to  add  a 
diagnostic  code  of  invalidTracelnformation  to 
allow  for  a  more  meaningful  description  of  this 
problem.  A  request  for  this  new  diagnostic  code 
will  be  submitted. 


7.8.3.6  Unsupported  X.400  Protocol  Elements 

The  protocol  elements  defined  in  X.400  but  unsupported  by 
this  profile  are:     the  def erredDelivery  and 

PerDomainBilaterallnfo  parameters  of  the  UMPDUEnvelope ,  the 
ExplicitConversion  parameter  of  Recipientlnfo ,  and  the 
alternateRecipientAllowed  and  contentReturnRequest  bits  of 
the  PerMessageFlag.     Appropriate  actions  are  described  below 
for  domains  that  do  not  support  the  protocol  elements. 
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7.8.3.6.1  def erredPe 1 ivery 

The  delivering  domain  shall  do  one  of  the  following: 

o      deliver  at  once, 

o      hold  for  deferred  delivery, 

o      return  a  nondelivery  notification  with  a  ReasonCode 
of  unableToTransf er  and  a  DiagnosticCode  of 
noBilateralAgreement . 

7.8.3.6.2  PerDomainBilaterallnfo 

If  a  delivering  domain  receives  this  element,  the 
element  can  be  ignored. 

7.8.3.6.3  ExplicitConversion 

If  ExplicitConversion  is  requested  the  message  should  be 
delivered  if  possible.     That  is,   if  the  UA  is  registered 
to  accept  the  EncodedlnformationTypes  of  the  message, 
then  the  message  should  be  delivered  even  though  the 
requested  conversion  could  not  be  performed  along  the 
route.     If  delivery  is  not  possible,   then  a  nondelivery 
report  should  be  generated  with  a  ReasonCode  of 
conversionNotPer formed  with  no  DiagnosticCode. 

7.8.3.6.4  alternateRecipientAl lowed 

If  a  delivering  domain  receives  this  element  the  element 
can  be  ignored. 

7.8.3.6.5  contentReturnRequest 

If  a  delivering  domain  receives  this  element,  the 
element  can  be  ignored. 

7.8.3.7  Unexpected  Values  for  INTEGER  Protocol  Elements 

There  are  three  INTEGERS  in  the  PI  Envelope.  Appropriate 
actions  are  described  below  for  domains  receiving  unexpected 
values  for  Priority,  ExplicitConversion,  and  ContentType. 
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7.8.3.7.1  Priority 

Additional  values  for  Priority  have  been  suggested  by  at 
least  one  group  of  implementors  as  upward  compatible 
changes  to  the  X.400  Recommendations.     Therefore,   if  a 
PRMD  receives  an  unexpected  value  for  Priority,   and  this 
value  is  greater  than  one  byte  in  length,  a  nondelivery 
report  should  be  generated  with  a  ReasonCode  of 
unableToTransfer  and  DiagnosticCode  of 
invalidParameters .     If  the  value  is  less  than  or  equal 
to  one  byte,   the  PRMD  can  either  generate  a  nondelivery 
■report  as  previously  specified  or  interpret  the  Priority 
as  normal  and  deliver  or  relay  the  message. 


7.8.3.7.2  ExplicitConversion 

When  an  unexpected  value  is  received  for 
ExplicitConversion,   it  should  be  handled  as  in  section 
7.8.3.6.3. 


7.8.3.7.3  ContentType 

If  the  ContentType  is  not  supported  by  the  delivering 
MTA,   then  a  nondelivery  report  should  be  generated  with 
a  ReasonCode  of  unableToTransfer,  and  a  DiagnosticCode 
of  contentTypeNotSupported. 


7.8.3.8  Additional  Elements 

In  the  absence  of  multilateral  agreements  to  the  contrary, 
receipt  of  privately  tagged  elements  and  protocol  elements 
in  addition  to  those  defined  in  X.400  will  result  in  a 
nondelivery  report  with  a  ReasonCode  of  unableToTransfer  and 
a  DiagnosticCode  of  invalidParameters. 

The  exceptions  to  this  are  the  MOTIS  elements.  The 
treatment  of  MPDU's  containing  these  MOTIS  extensions  is 
described  in  section  7.6.11. 


7.8.4  Reports 

There  is  no  mechanism  for  returning  a  delivery  or  status  report 
due  to  errors  in  the  report  itself.     Therefore  the  handling  of 
errors  in  reports  is  a  local  matter. 
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7.9     MHS  USE  OF  DIRECTORY  SERVICES 


7.9.1        Directory  Service  Elements 

a)     Recommendation  X.400  recognizes  the  need  of  MHS  users 
for  a  number  of  directory  service  elements.  Directory 
service  elements  are  intended  to  assist  users  and  their 
UAs  in  obtaining  information  to  be  used  in  submitting 
messages  for  delivery  by  the  MTS .     The  MTS  may  also  use 
directory  service  elements  to  obtain  information  to  be 
used  in  routing  messages.     Some  functional  requirements 
of  directories  have  been  identified  and  are  listed 
below. 

o      Verify  the  existence  of  an  0/R  name. 

o      Return  the  0/R  address  that  corresponds  to  the  0/R  name 
presented. 

o      Determine  whether  the  0/R  name  presented  denotes  a  user 
or  a  distribution  list. 

o      Return  a  list  of  the  members  of  a  distribution  list. 

o      When  given  a  partial  name,  return  a  list  of  0/R  name 
possibilities . 

o      Allow  users  to  scan  directory  entries. 

o      Allow  users  to  scan  directory  entries  selectively. 

o      Return  the  capabilities  of  the  entity  referred  to  by  the 
0/R  name . 

o      Provide  maintenance  functions  to  keep  the  directory 
up-to-date . 

b)  In  addition  to  functionality,  a  number  of  operational 
aspects  must  be  considered.     These  include 

user-friendliness,  flexibility,  availability,  expendability , 
and  reliability. 

c)  Currently,   these  aspects  of  directory  service  elements  and 
procedures  are  under  study  by  both  the  CCITT  and  the  ISO. 
Both  organizations  are  committed  to  the  development  of  a 
single  Directory  Service  specification  for  use  by  MHS  and 
all  other  OSI  based  applications. 
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Given  the  incomplete  nature  of  the  ongoing  activities  within 
the  CCITT  and  the  ISO,  no  implementation  details  will  be 
provided  now  for  MHS  use  of  Directory  Services. 
Implementation  agreements  for  MHS  Use  of  Directory  Services 
will  be  issued  when  current  activities  within  the  CCITT  and 
the  ISO  are  stable. 


7.9.2        Use  of  Names  and  Addresses 

a)  It  is  recognized  that  these  agreements  enable  a  wide  variety 
of  naming  and  addressing  attributes  (see  sec.  7.5.3.5 
ORName  Protocol  Elements)  wherein  each  PRMD  may  adopt 
particular  routing  schemes  within  its  domain. 

b)  With  the  exception  of  the  intra-domain  connection 
agreements : 

These  agreements  make  no  attempt  to  recommend  a  standard 
practice  for  electronic  mail  addressing. 

c)  Inter-PRMD  addressing  may  be  secured  according  to  practices 
outside  the  scope  of  these  agreements,   such  as: 

o    manual  directories 

o    on-line  directories 

o    ORName  address  specifications 

o    ORName  address  translation. 

d)     Further,  each  PRMD  may  adopt  naming  and  addressing 
schemes  wherein  the  user  view  may  take  a  form 
entirely  different  from  the  attributes  reflected  in 
table  7.9.     And,  each  PRMD  may  have  one  user  view 
for  the  originator  form  and  another  for  the 
recipient  form,  and  perhaps  other  forms  of  user 
addressing.     In  some  cases  (e.g.,  receipt 
notification)  these  user  forms  must  be  preserved 
within  the  constraints  of  these  implementation 
agreements.     However,  mapping  between  one  PRMD  user 
form  to  another  PRMD  user  form,  via  the  X.400  ORName 
attributes  of  these  agreements,   is  outside  the  scope 
of  these  agreements. 


7.10  CONFORMANCE 
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7.10.1  Introduction 

In  order  to  ensure  that  products  conform  to  these  implementation 
agreements ,   it  is  necessary  to  define  the  types  and  degrees  of 
conformance  testing  that  products  must  pass  before  they  may  be 
classified  as  conformant .     This  section  defines  the  conformance 
requirements  and  provides  guidelines  for  the  interpretation  of 
the  results  from  this  type  of  testing. 

This  section  is  incomplete  and  will  be  enhanced  in  future 
versions  of  this  Agreement.     Later  versions  will  reflect  the 
problems  of  conformance  testing  and  will  outline  specific 
practices  and  recommendations  to  aid  the  development  of 
conformance  tests  and  procedures. 

7.10.2  Definition  of  Conformance 

For  this  section,   the  term  conformance  is  defined  by  the 
following : 

a)  The  tests  indicated  for  this  section  are  intended  to 
establish  a  high  degree  of  confidence  in  a  statement  that 
the  implementation  under  test  (lUT)  conforms  (or  does  not 
conform)  to  the  agreements  of  this  section. 

b)  Conformance  to  a  service  element  means  that  the  information 
associated  with  the  service  element  is  made  accessible  to 
the  user  (person  or  process)  whenever  this  agreement  says 
that  this  information  should  be  available. 

Accessible  means  that  information  must  be  provided 
describing  how  a  user  (person  or  process) : 

o      causes  appropriate  information  to  be  displayed,  or 
o      causes  appropriate  information  to  be  obtained. 

c)  Conformance  to  PI,   P2 ,   and  RTS  as  part  of  an  X.400  OSI 
application  requires  that  only  the  external  behavior  of  that 
OSI  system  adheres  to  the  relevant  protocol  standards. 

In  order  to  achieve  conformance  to  this  section,  it  is  not 
required  that  the  inter- layer  interfaces  be  available  for 
testing  purposes. 

d)  Conformance  to  the  protocols  requires: 

o      that  MPDUs  correspond  to  instances  of  syntactically 
correct  data  units,  , 
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o      MPDUs  in  which  the  data  present  in  the  fields  and  the 
presence  (or  absence)  of  those  fields  is  valid  in  type 
and  semantics  as  defined  in  X.400,  as  qualified  by  this 
profile, 

o      correct  sequences  of  protocol  data  units  in  responses 
(resulting  from  protocol  procedures). 

Statements  regarding  the  conformance  of  any  one 
implementation  to  this  profile  are  not  complete  unless  a 
Protocol  Implementation  Conformance  Statement  (PICS)  is 
supplied. 

The  term  "Implementation  Under  Test"   (lUT)  is 
interchangeable  with  the  term  "system"  in  the  definition  of 
conformance .  and  may  refer  to: 

o      a  domain,  which  may  be  one  or  more  MTA's  with  co- located 
or  remote  UA's, 

o      a  single  instance  of  an  MTA  and  co- located  UA  with  X.400 
(PI,  P2,  RTS  and  session)  software, 

o      a  relaying  product  with  PI,  RTS  and  session  software, 

o      a  gateway  product. 

Claiming  Implementation  Conformance 

o      An  implementation  which  claims  to  be  conformant  as  an 
ADMD  must  adhere  to  the  agreements  in  sections  7.5  and 
7.6. 

o      An  implementation  which  claims  to  be  conformant  as  a 
PRMD  must  adhere  to  the  agreements  in  section  7.5. 

o      An  implementation  which  claims  to  be  conformant  as  a 
relaying  PRMD  must  adhere  to  the  agreements  in  section 
7.5  and  the  appropriate  sections  of  7.7. 

o      An  implementation  which  claims  to  be  conformant  to  the 
intra-domain  connection  agreements  must  adhere  to  the 
agreements  in  section  7.5  and  the  appropriate  sections 
of  7.7. 
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7.10.3      Conformance  Requirements 
7.10.3.1  Introduction 

Conformance  to  this  specification  requires  that  all  the 
services  listed  as  supported  in  sections  7.5,   7.6,  and  if 
appropriate,   7.7  of  these  agreements  are  supported  in  the 
manner  defined,   in  either  the  CCITT  X.400  Recommendations  or 
these  agreements.     It  is  not  necessary  to  implement  the 
recommended  practices  of  section  7.12,  Appendix  B,   in  order 
to  conform  to  these  agreements . 

It  is  the  intention  to  adopt,  where  and  when  appropriate  the 
testing  methodology  and/or  the  abstract  test  scenarios 
currently  being  defined  by  the  CCITT  X.400  Conformance 
Group.     However,   it  is  recognized  that  formal  CCITT 
Recommendations  relating  to  X.400  Conformance  Testing  will 
not  be  available  until  1988.     It  is  also  recognized  that 
aspects  of  these  agreements  are  outside  the  scope  of  the 
CCITT,  and  that  other  organizations  will  have  to  provide 
conformance  tests  in  these  cases. 


7.10.3.2        Initial  Conformance 

This  section  is  intended  to  provide  guidelines  to  vendors 
who  envisage  having  X.400  products  available  prior  to  any 
formal  mechanism,   or  "Conformance  Test  Center"  being  made 
accessible  that  would  allow  for  conformance  to  this  product 
specification  to  be  tested. 

It  is  feasible  that  vendors  and  carriers  will  want  to  enter 
bilateral  test  agreements  that  will  allow  for  initial  trials 
to  be  carried  out  for  the  purposes  of  testing  initial 
interworking  capabilities.     It  is  equally  feasible  that  for 
the  purposes  of  testing  interoperability,  only  a  subset  of 
this  specification  will  initially  be  tested. 

Note:  By  claiming  conformance  to  this  subset  of 
information  the  vendor  or  carrier  CANNOT  claim 
conformance  to  this  entire  specification. 

There  are  two  aspects  to  the  requirements,   interworking  and 
service,   as  described  in  the  following  sections. 
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7.10.3.2.1  Interworklng 

The  interworking  requirements  for  conformance  implies 
that  tests  be  done  to  check  for  the  syntax  and  semantics 
of  protocol  data  elements  for  a  system  as  defined  by  the 
classification  scheme  of  sections  7.5.2.1.1  and  7.7.5.2. 
For  a  relay  system,  the  correct  protocol  elements  should 
be  relayed  as  appropriate.     For  a  recipient  system,  a 
message  with  correct  protocol  elements  must  not  be 
rejected  where  appropriate. 

7. 10.3.2.2  Service 

For  information  available  to  the  recipients  via  the 
IPMessage  Heading  and  Body,  the  following  should  be  made 
accessible: 

o      IPMessage  ID  -  only  the  PrintableString  portion  of 

the  IPMessageld  needs  to  be  accessible, 
o  subject, 
o      primaryRecipients , 
o      copyRecipients , 
o      blindcopyRecipients , 
o      authorizingUsers , 
o  originator, 
o  inReplyTo, 
o      replyToUsers , 
o      importance , 
o  sensitivity, 
o      IA5Text  Bodypart. 
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7 .11        APPENDIX  A:     INTERPRETATION  OF  X.400  SERVICE  ELEMENTS 

The  work  on  service  element  definitions  is  limited  to  those  that  are 
defined  as  'supported'   in  section  7.5  of  this  specification.  Furthermore 
it  is  not  the  intent  of  this  section  to  define  how  information  should  be 
made  available  or  presented  to  a  MHS  user,  nor  is  it  intended  to  define 
how  individual  vendors  should  design  their  products.     In  addition, 
statements  on  conformance  to  a  specific  service  element  and  the 
allocation  of  error  codes  that  are  generated  as  a  result  of  violations  of 
the  service  should  be  defined  in  the  sections  on  conformance  and  errors 
as  part  of  the  main  product  specification.     The  main  objective  is  to 
provide  clarification,  where  required,  on  the  functions  of  a  service 
element,  and  in  particular  what  the  original  intent  of  the 
Recommendations  were. 

SERVICE  ELEMENTS 

The  following  Service  Elements  defined  in  X.400  have  been  examined  and 
require  further  text  to  be  added  to  their  definitions  to  represent  the 
proposed  implementation  of  these  service  elements  by  the  X.400  SIG. 

The  service  element  clarifications  are  to  be  taken  in  the  context  of  this 
profile. 

Service  elements  not  referenced  in  this  section  are  as  defined  in  X.400. 

PROBE 

A  PRMD  need  not  generate  probes. 

If  a  probe  is  addressed  to  and  received  by  a  PRMD,   the  PRMD  must  respond 
with  a  Delivery  Report  as  appropriate  at  the  time  the  probe  was 
processed . 

DEFERRED  DELIVERY 

In  the  absence  of  bilateral  agreements  to  the  contrary.  Deferred  Delivery 
and  Deferred  Delivery  Cancellation  are  local  matters  (i.e.,  confined  to 
the  originating  domain)  and  need  not  be  provided. 

The  extension  of  Deferred  Delivery  beyond  the  boundaries  of  the 
initiating  domain  is  via  bilateral  agreement  as  specified  in  section 
3.4.2.1  of  X.411. 

Content  Type  Indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to 
support  P2  content  type.     The  ability  for  domains  to  be  able  to  exchange 
content  types  other  than  P2  will  depend  on  the  existence  of  bilateral  or 
multi- lateral  agreements. 
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Original  Encoded  Information  Types  Indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to 
support  IA5  text.     Support  for  other  encoded  information  types,   for  the 
purposes  of  message  transfer  between  domains,  will  depend  on  the 
existence  of  bilateral  or  multi- lateral  agreements. 

The  use  of  the  'unspecified'   form  of  encoded  information  type  should  only 
be  used  when  the  UMPDU  content  represents  an  SR-UAPDU  or  contains  an 
auto -forwarded  IM-UAPDU. 

The  original  encoded  information  type  of  a  message  is  not  meaningful 
unless  a  message  is  converted  en  route  to  the  recipient.  These 
agreements  support  only  IA5  text,  which  should  not  undergo  conversion. 
The  original  encoded  information  types  should  be  made  accessible  to  the 
recipient  for  upward  compatibility  with  the  use  of  non-IA5  text  message 
body  parts . 

Registered  Encoded  Information  Types 

A  UMPDU  with  an  'unspecified'  value  for  Original  Encoded  Information  Type 
shall  be  delivered  to  the  UA. 

Delivery  Notification 

The  UAContentID  may  be  used  by  the  recipient  of  the  delivery  notification 
for  correlation  purposes. 

Disclosure  of  Other  Recipients 

This  service  is  not  made  available  by  originating  MTAE's  to  UAE's,  but 
must  be  supported  by  relaying  and  recipient  MTAE's. 

By  supporting  the  disclosure  of  other  recipients  the  message  recipient 
can  be  informed  of  the  O/R  names  of  the  other  recipient(s)  of  the 
message,  as  defined  in  the  PI  envelope,   in  addition  to  the  O/R 
Descriptors  within  the  P2  header. 

These  agreements  do  not  support  initiation  of  disclosure  of  other 
recipients,  but  the  information  associated  with  it  should  be  made 
accessible  to  the  recipient  for  upward  compatibility  with  support  for  the 
initiation  of  this  service  element. 

Typed  Body 

As  defined  in  X.400  with  the  addition  of  the  Private  Body  Types  that  are 
to  be  supported.  At  present  there  is  no  mechanism  provided  within  X.420 
that  would  allow  you  to  respond  to  reception  of  an  unsupported  body  type. 

Action  taken  in  this  situation  is  a  local  matter. 
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Blind  Copy  Recipient  Indication 

It  should  be  considered  that  the  recipient's  UA  acts  on  behalf  of  the 
recipient,  and  therefore  may  choose  to  disclose  all  BCC  recipients  to 
each  other.     Therefore  it  is  the  responsibility  of  the  originating  domain 
to  submit  two  or  more  messages,  depending  on  whether  or  not  each  BCC 
should  be  disclosed  to  each  other  BCC. 

Auto  Forwarded  Indication 

A  UA  may  choose  not  to  forward  a  message  that  was  previously 
auto- forwarded.  In  addition  there  is  no  requirement  for  an  IPM  UA  that 
does  not  support  non-receipt  or  receipt  notification  to  respond  with  a 
non-receipt  notification  when  a  message  is  auto -forwarded. 

Primary  and  Copy  Recipients  Indication 

It  is  required  that  at  least  one  primary  recipient  be  specified;  however, 
for  a  forwarded  message  this  need  not  be  present.     The  recipient  UA 
should  be  prepared  to  accept  no  primary  and  copy  recipients  to  enable 
future  interworking  with  Teletex,  Fax,  etc. 

Sensitivity  Indication 

A  message  originator  should  make  no  assumptions  as  to  the  semantic 
interpretation  by  the  recipients  UA  regarding  classifications  of 
sensitivity.  For  example,  a  personal  message  may  be  printed  on  a  shared 
printer . 

Reply  Request  Indication 

In  requesting  this  service  an  originator  may  additionally  supply  a  date 
by  which  the  reply  should  be  sent  and  a  list  of  the  intended  recipients 
of  the  reply.   If  no  such  list  is  provided  then  the  initiator  of  the  reply 
sends  the  reply  to  the  originator  of  the  message  and  any  recipients  the 
reply  initiator  wishes  to  include.  The  replytoUsers  and  the  replyBy  date 
may  be  specified  without  any  explicit  reply  being  requested.  This  may  be 
interpreted  by  the  recipient  as  an  implicit  reply  request.  Note  that  for 
an  auto -forwarded  message  an  explicit  or  implicit  reply  request  may  not 
be  meaningful . 

Body  Part  Encryption 

The  original  encoded  information  type  indication  includes  the  encoded 
information  type(s)  of  message  body  parts  prior  to  encryption  by  the 
originating  domain.     The  ability  for  the  recipient  domain  to  decode  an 
encrypted  body  part  is  a  local  matter.     Successful  use  of  this  facility 
can  only  be  guaranteed  if  there  exists  bilateral  agreements  to  support 
the  exchange  of  encrypted  body  parts . 
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Forwarded  IP  message  Indication 

The  following  use  of  the  original  encoded  information  type  in  the  context 
of  forwarded  messages  is  clarified: 

o        If  forwarding  a  private  message  body  part  the  originator  of  the 
forwarded  message  shall  set  the  original  encoded  information 
types  in  the  PI  envelope  to  undefined  for  that  body  part. 

o        The  encoded  information  types  of  the  message  being  forwarded 

should  be  reflected  in  the  new  original  encoded  information  types 
being  generated. 

o        See  Appendix  7B  on  recommended  practices  for  the  use  of  the 
delivery  information  as  part  of  Forwarded  IP-message. 

Multipart  Body 

It  is  the  intent  of  multipart  bodies  to  allow  for  the  useful  and 
meaningful  structuring  of  a  message  that  is  constructed  using  differing 
body  part  types.     For  example,  it  is  not  recommended  that  a  message  made 
up  of  only  IA5  text  should  be  represented  as  a  number  of  IA5  body  parts, 
each  one  representing  a  paragraph  of  text. 
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7.12  APPENDIX  B:     RECOMMENDED  X.400  PRACTICES 

It  is  not  necessary  to  follow  the  recommended  practices  when  claiming 
conformance  to  these  agreements . 

7. 12. 1  RECOMMENDED  PRACTICES  IN  P2 

1.  ORDescriptor 

■  -  Vendors  following  the  NIST/OSI  Workshop  guidelines  shall, 

whenever  possible,   generate  the  ORName  portion  of  an 
ORDescriptor  in  ALL  IPM  heading  fields. 

2.  ForwardedlPMessage  BodyParts 

ForwardedlPMessage  BodyParts  should  be  nested  no  deeper  than 
eight.     There  is  no  restriction  on  the  number  of 
ForwardedlPMessage  BodyParts  at  any  given  depth. 

3.  Deliverylnformation 

It  is  strongly  recommended  that  Deliverylnformation  be 
supplied  in  both  forwarded  and  autoforwarded  message  body 
parts.   Deliverylnformation  is  useful  when  a  message  has 
multiple  forwarded  message  body  parts  because  without  it, 
the  EncodedlnformationType(s)  of  the  component  forwarded 
messages  cannot  be  deduced  easily.     Deliverylnformation  is 
useful  for  autoforwarded  messages  because  the 
EncodedlnformationType  of  an  autoforwarded  message  is 
"unspecified"  and  the  Encodedinf ormationType ( s )  of  the 
message  cannot  be  determined  easily  without  it.  Absence  of 
the  EncodedlnformationType (s)  makes  it  difficult  for  a  UA  to 
easily  determine  whether  the  message  can  be  rendered. 

7.12.2  RECOMMENDED  PRACTICES  IN  RTS 

1.  In  the  case  where  S-U-ABORT  indicates  a  temporaryProblem , 
reestablishment  of  the  session  should  not  be  attempted  for  a 
"sensible"  time  period  (typically  not  less  than  5  minutes). 

In  instances  where  this  delay  is  not  required  or  necessary, 
report  a  localSystemProblem. 

2.  S-U- EXCEPTION-REPORT  reason  codes  can  be  interpreted  as 
follows : 

o      receiving  ability  jeopardized  (value  1) 
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Possible  meaning:  The  receiving  RTS  knows  of  an 
impending  system  shutdown. 

o      local  ss-User  error  (value  5) 

Possible  meaning:     The  receiving  RTS  needs  to 
resynchronize  the  session  dialogue. 

o      irrecoverable  procedure  error  (value  6) 

Possible  meaning:     The  receiving  RTS  has  had  to  delete  a 
partially  received  APDU,  even  though  some  minor 
synchronization  points  have  been  confirmed. 

o      non  specific  error  (value  0) 

Possible  meaning:     The  receiving  RTS  cannot  handle  the 
APDU  (for  example,  because  it  was  too  large)  and  wishes 
to  inform  the  sending  RTS  not  to  try  again. 

o      sequence  error  (value  3): 

Possible  meaning:  The  S -ACTIVITY-RESUME  request 
specified  a  minor  synchronization  point  serial  number 
which  does  not  match  the  checkpoint  data. 

3.       For  purposes  of  identifying  an  MTA  during  an  RTS  Open,  OS I 
addressing  information  should  be  used.     This  addressing 
information  is  conveyed  by  lower  layer  protocols  and  is 
reflected  by  the  calling  and  called  SSAP  parameters  of  the 
S-CONNECT  primitives. 

MTA  validation  and  identification  are  related,  but  separate, 
functions.     The  mTAName  and  password  protocol  elements  of 
the  RTS  user  data  should  be  used  for  validation,  rather  that 
identification,  of  an  MTA.     The  RTS  initiator  and  responder 
may  independently  require  each  other  to  supply  mTAName  and 
password. 

The  CallingSSUserReference  parameter  of  the  S-CONNECT 
primitives  should  only  have  meaning  to  the  entity  that 
encoded  it  and  should  not  be  used  to  identify  an  MTA. 


7.12.3      RECOMMENDED  PRACTICES  FOR  ORName 

Table  7.9  stipulates  that  the  StandardAttributeList  must  contain 
either  PrivateDomainName  or  OrganizationName .     It  is  recommended 
that,  for  both  originator  and  recipients  in  a  private  domain,  the 
PrivateDomainName  field  be  used. 

It  is  recommended  that  there  should  be  a  DomainDef inedAttribute 
to  be  used  in  addressing  UAs  in  existing  mail  systems,  in  order 
to  curtail  the  proliferation  of  different  types  of 
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DomainDef inedAttributes  used  for  the  same  purpose.     The  syntax  of 
this  DomainDef inedAttribute  conforms  to  the  CCITT  Pragmatic 
Constraints,  and  thus  has  a  maximum  value  length  of  128  octets 
and  a  type  length  of  8  octets,  each  of  type  Printable  String. 
Only  one  occurrence  is  allowed. 

This  DomainDef inedAttribute  has  the  type  name  "ID"  (in 
uppercase) .     It  contains  the  unique  identifier  of  the  UA  used  in 
addressing  within  the  domain.     This  DomainDef inedAttribute  is  to 
be  exclusively  used  for  routing  within  the  destination  domain 
(i.e.,  once  routed  to  that  domain  via  the  mandatory  components  of 
the  StandardAttributeList) ;   any  other  components  of  the 
StandardAttributeList  may  be  provided.     If  they  conflict  delivery 
is  not  made. 

The  contents  of  this  parameter  need  not  be  validated  in  the 
originating  domain  or  any  relaying  domain,  but  simply  transferred 
intact  to  the  next  MTA  or  domain. 

Class  2  and  class  3  MTAs  in  a  PRMD  should  allow  administrators  to 
decide  the  number  of  OrganizationalUnits  that  should  appear  in 
user  names,   instead  of  imposing  a  software  controlled  limit  which 
is  less  than  four.     This  is  desirable  because  when  two  different 
vendors  impose  different  limits  on  the  number  of 
OrganizationalUnits  in  a  name,   it  becomes  difficult  for  the 
administrator  to  choose  a  sensible  naming  scheme. 

There  are  existing  mail  systems  that  include  a  small  set  of  non- 
Printable  String  characters  in  their  identifiers.     For  these 
systems  to  communicate  with  X.400  messaging  systems,   either  for 
pass-through  service  or  delivery  to  X.400  users,  gateways  will  be 
employed  to  encode  these  special  characters  into  a  sequence  of 
Printable  String  characters.     This    conversion  should  be 
performed  by  the  gateway  according  to  a  common  scheme  and  before 
insertion  in  the  ID  DDA,  which  is  intended  to  carry  electronic 
mail  identifiers.     X.400  User  Agents  may  also  wish  to  perform 
such  conversions. 

It  is  recommended  that  the  following  symmetrical  encoding  and 
decoding  algorithm  for  non-Printable  String  characters  be 
employed  by  gateways.     The  encoding  algorithm  maps  an  ID  from  an 
ASCII  representation  to  a  PrintableString  representation.  Any 
non-printable  string  characters  not  specified  in  the  table  are 
covered  by  the  category  "other"  in  the  table  below. 
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The  principal  conversion  table  for  the  mapping  is  as  follows: 
Table  7B.1.     Printable  string  to  ASCII  mapping 


ASCII  Character 

Printable  String  Character 

%  (percent) 

(P) 

@  (at  sign) 

(a) 

!  (exclamation) 

(b) 

"   (quote  mark) 

(q) 

_  (underline) 

(u) 

(   (left  paren. ) 

(1) 

)   (right  paren, ) 

(r) 

other 

(3DIGIT) 

where  3DIGIT  has  the  range  000  to  377  and  is  interpreted  as  the  octal 
encoding  of  an  ASCII  character. 

To  encode  an  ASCII  representation  to  a  PrintableString ,  the  table  and  the 
following  algorithm  should  be  used: 

IF  current  character  is  in  the  encoding  set  THEN 

encode  the  character  according  to  the  table  above 

ELSE 

write  the  current  character; 
continue  reading; 

To  decode  a  PrintableString  representation  to  an  ASCII  representation, 
the  table  and  the  following  algorithm  should  be  used: 

IF  current  character  is  not  "("  THEN 

write  character 
ELSE 

( 

look  ahead  appropriate  characters; 

IF  composite  characters  are  in  the  above  table  THEN 

decode  per  above  table 
ELSE 

write  current  character; 

} 

continue  reading; 

Class  2  and  class  3  MTAs  in  a  PRMD  should  allow  administrators  to 
decide  the  number  of  OrganizationalUnits  that  should  appear  in 
user  names,  instead  of  imposing  a  software  controlled  limit  which 
is  less  than  four.     This  is  desirable  because  when  two  different 
vendors  impose  different  limits  on  the  number  of 
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OrganizationalUnits  in  a  name,   it  becomes  difficult  for  the 
administrator  to  choose  a  sensible  naming  scheme. 

7. 12.4      POSTAL  ADDRESSING 

For  domains  wishing  to  support  postal  (or  physical)  delivery 
options,  the  following  interim  set  of  "nationally-defined"  domain 
defined  attributes  are  recommended.     The  CCITT  will  define 
Standard  Attributes  in  support  of  physical  delivery  in  its  1988 
Recommendations;  this  is  only  an  interim  solution. 

CCITT  will  also  be  addressing  the  services  associated  with 
physical  delivery.  This  interim  solution  does  not  address  the 
end-to-end  service  aspects  of  physical  delivery;   in  particular, 
the  following  IPM  service  elements  do  not  currently  extend 
outside  of  the  X.400  environment: 

o  alternate  Recipient  Assignment 

o  PROBE 

o  Receipt  Notification  /  Non-Receipt  Notifications 

o  Grade  of  delivery 

"Delivery"  means  passing  a  message  from  the  MTS  to  the  physical 
delivery  system  (PDS),  and  not  to  the  user  (or  user  agent). 

The  following  three  DDAs  are  recommended  to  be  used  to  specify  a 
postal  (or  physical)  address: 

CNTRPC      encodes  the  country  and  postal  code  for  postal  delivery. 

The  DDA  value  is  of  the  form  "Country?Postalcode"  (for 
example,   "USA722096" ) .     The  country  field  is  optional, 
the  postal  code  is  optional;  the  separator  ("?")  is  not. 
If  both  country  and  postal  code  are  missing,   this  DDA 
should  not  be  specified. 

PDA  1        The  country  and  postal  code  fields  are  free-form  text. 

PDA  2        These  two  DDA  (signifying  Postal  Delivery  Address 

strings  1  and    2)  form  a  256  character  free-form  postal 
address.     Fields  are  separated  by  a  question  mark  ("?"). 
There  is  no  implied    separator  between  PDAl  and  PDA2 . 
The  meaning  of  the  fields  are  defined  by  each  domain 
supporting  the  physical  delivery  interface.  PDAl 
contains  the  first  128  characters,  PDA2  the  next  128 
characters.     If  the  PDA  string  is  less  than  128 
characters,  PDA2  is  not  used. 
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For  example,  if  the  domain  interprets  the  PDA  fields  as  lines, 
the  address 

Mr.  John  Smith 
Conway  Steel 
123  Main  Street 
Reston  VA  22096 

would  be  encoded  as  follows: 

type  =  "PDAl"    value  =  "Mr.  John  Smith?Conway  Steel?123  Main 
Street?Reston  VA" 
CNTRPC  =  "722096" 


7.12.5      EDI  use  of  X.400 


7.12.5.1  Introduction  and  Scope 

This  is  a  guideline  for  EDI  data  transfer  in  an  X.400 
environment  conforming  to  the  NIST  agreements.  These 
recommended  practices  outline  procedures  for  use  in 
transferring  EDI  transactions  between  trading  partner 
applications  in  an  attempt  to  facilitate  actual  X.400 
implementation  by  EDI  users. 

The  scope  of  this  guideline  is  to  describe  specific 
recommendations  for  adopting  X.400  as  the  data  transfer 
mechanism  between  EDI  applications. 

7.12.5.2  Model 

The  MHS  recommendations  can  accommodate  EDI  through  the 
approach  illustrated  below.     Many  Message  Transfer  (MT) 
service  elements  defined  in  the  X.400  recommendations  are 
particularly  useful  to  the  EDI  application. 
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X.400  Message  (1  EDI  interchange) 


Envelope 


 > 


PI  Control 
Information 


Content 


 > 


One 
EDI 

Interchange 


MHS  Message 


This  diagram  depicts  an  EDI  content  (1  EDI  interchange) 
enveloped  by  the  PI  MHS  envelope.     All  the  MT  Services 
defined  in  the  X.400  Recommendations  may  be  used  for  EDI. 
However,   it  is  not  required  to  support  optional  or  non- 
essential services  to  exchange  EDI  data  between  EDI  users. 
When  an  EDI  user  submits  an  EDI  Trade  Document  to  the  EDI 
User  Agent,   the  EDI  UA  will  submit  the  EDI  content  plus  PI 
envelope  to  the  Message  Transfer  System  (MTS) . 


The  EDI  UA  must  support  the  essential  MT  Services  as  defined 
in  these  Agreements;  for  example,  as  a  minimum,   to  provide 
default  values  for  services  not  elected  by  the  EDI  user, 
such  as  Grade  of  Delivery. 

Note:       MT    Services    are   not   necessarily   made    available  by 
the  EDI  UA  to  the  EDI  user. 
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7.12.5.3        Protocol  Elements  Supported  for  EDI 

The  following  Pi  protocol  elements  will  be  used  to  support 
EDI  applications: 

Content  Type 

For  EDI  applications,   the  content  type  will  be  0 
(undefined  content) . 

Original  Encoded  Information  Types 

Any  EIT  defined  in  the  X.400  Recommendations  may  be  used 
to  specify  the  encoding  of  EDI  content.     However,  for 
ANSI  X12  EDI  applications  in  particular,   it  is  expected 
that  the  "undefined"  and  "laSText"  EIT's  will  normally 
be  used,  with  "undefined"  used  to  signify  the  EBCDIC 
character  set. 


7.12.5.4       Addressing  and  Routing 

It  is  anticipated  that  connection  of  some  existing  systems 
to  an  X.400  service  for  EDI  purposes  will  be  by  other  than 
X.400  protocols,  at  least  in  the  short  term. 

EDI  messages  entering  the  X.400  environment  will  therefore 
need  to  have  X.400  0/R  Names  added  to  identify  the 
origination  and  recipient  trading  partners,  typically  by 
means  of  local  directory  services  in  the  origination  domain 
which  will  map  EDI  identifiers/addresses  into  0/R  Names. 
Such  0/R  Names  will  contain  Standard  Attributes  as  defined 
in  table  7.9  and  for  recipient  trading  partners  will  at 
least  identify  the  destination  domain. 

In  the  case  of  trading  partners  outside  the  X.400 
environment,   it  is  expected,  however,  that  there  will  be 
cases  where  message  delivery  will  require  the  provision  of 
addressing  information  beyond  that  which  can  be  carried  in 
Standard  Attributes.     In  such  cases.  Domain  Defined 
Attributes  are  recommended  to  be  used. 

The  syntax  of  this  DDA  is  as  defined  in  table  7.9,  with  a 
single  occurrence  having  the  type  name  "EDI"  (uppercase)  and 
a  value  containing  the  identifier/address  of  the  trading 
partner.     For  ASC  X12  purposes,  specifically,  this  value 
will  comprise  the  2  digit  interchange  ID  qualifier  followed 
by  the  interchange  ID  (max  15  characters) .     Routing  on  this 
DDA  shall  only  occur,   if  at  all,   in  the  destination  domain. 
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7.12.6  USA  Body  Parts 

It  is  recommended  that  UAs  can  generate  any  USA  Body  Part,  as 
defined  in  Section  7.5.3.6.2,  and  that  they  can  receive  such  body 
parts  as  well.     reception  of  USA  Body  Parts  does  not  imply 
further  processing  by  the  UA,  but  merely  that  the  body  part  is 
made  available,  with  a  indication  of  its  registered  body  part 
identifier,   to  another  process  or  deposition  in  a  file. 
Generation  implies  the  reverse  of  this  process. 

7.12.7  Recommended  Practices  for  Binary  Data  Transfer 

The  capability  to  transfer  binary  data,   such  as  those  generated 
by  word/ document  processing,  spreadsheets,  or  graphics 
applications  among  X.400  system  is  a  useful  and  desirable 
feature.     Many  messaging  systems  provide  such  capability  today. 

It  is  recommended  that  transfer  of  binary  data  through  1984-based 
systems  be  achieved  using  the  Unidentified  BodyPart  in  P2  with 
the  ASNl  definition  recaptured  as  follows: 

BodyPart        : :=  CHOICE  { 

[0]   IMPLICIT  lASText 

[14]   IMPLICIT  Unidentified 
.  .  .  ) 

Unidentified     : :=  OCTET  STRING 

Note:  the  Unidentified  BodyPart  is  included  in  1984  X.400 
Implementor ' s  Guide,  Version  6,  and  is  renamed  as 
BilaterallyDefinedBodyPart  in  1988  X.400  Series  with  the 
same  tag  and  definition. 

Additionally  the  binary  data  can  be  identified  by  a  text 
string  in  the  subject  heading  or  in  an  IA5Text  body  part 
preceding  the  Unidentified  BodyPart. 

When  the  Unidentified  BodyPart  is  present  in  a  P2 
message,  the  undefined(O)  bit  of  the  PI 
EncodedlnformationTypes  will  be  set.  If  the  lASText 
bodypart  is  also  present,  the  IA5text(2)  bit  will  also 
be  set. 

The  binary  data  is  the  raw  data  as  generated  by  user 
applications.  Besides  encapsulating  it  for  transfer 
purposes,  X.400  systems  do  not  encode  or  interprete  the 
binary  data  in  any  way  further.  How  the  data  is  encoded 
or     decoded     is     defined     by     the     cooperating  user 
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applications.  How  the  data  is  injected  into  X.400 
systems  or  transferred  out  of  X.400  systems  to  the  user 
applications,  or  how  the  user  applications  are  invoked 
to  process  the  data  is  a  local  implementation  issue  and 
not  defined. 


7.12.8      Recommended  Practice  for  Office  Document  Architecture 
(PDA')  Transfer 

It  is  recommended  that  the  conveyance  of  ODA  documents  through 
1984-based  X.400  systems  be  achieved  using  the  following  schemes: 

(a)  In  P2: 

An  ODA  document  will  be  transferred  as  a  single  body  part 
with  tag  12,  recaptured  as  follows: 

BodyPart     : :=    CHOICE  { 

[0]     IMPLICIT  IA5Text 

oda  [12]   IMPLICIT  OCTET  STRING 

.  .  .  } 

The  content  of  the  Octet  String  will  contain  a  value  of  type 
OdaBodyPart  as  follows: 

OdaBodyPart    : :=    SEQUENCE  { 

OdaBodyPartParameters , 
OdaData  } 

The  Parameters  and  Data  components  are  defined  in  Annex  E  of 
CCITT  Recommendation  T.411  (1988)   (ISO  8613-1). 

(b)  In  PI: 

Both  the  undefined  bit  (bit  0)  and  the  ODA  bit  (bit  10)  of 
the  EncodedlnformationType  will  be  set  when  an  ODA  document 
is  present  in  P2 . 
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7.13  APPENDIX  C:     RENDITION  OF  lASText  AND  T61String  CHARACTERS 

7.13.1  GENERATING  AND  IMAGING  lASText 

The  characters  that  may  be  used  in  an  lASString  are  the  graphic 
characters  (including  Space),  control  characters  and  Delete  of 
the  IA5  character  repertoire  ISO  646. 

The  graphic  characters  that  may  be  used  with  a  guaranteed 
rendition  are  those  related  with  positions  2/0  to  2/2,  2/5  to 
3/15,  4/1  to  5/10,  5/15  and  6/1  to  7/10  in  the  basic  7-bit  code 
table . 

The  other  graphic  characters  may  be  used  but  have  no  guaranteed 
rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed 
effect  are  a  subset  consisting  of  the  format  effectors  0/10  (LF) , 
0/12  (FF)  and  0/13  (CR)  provided  they  are  used  in  one  of  the 
following  combinations: 

CR  LF  to  start  a  new  line 

CR  FF  to  start  a  new  page  (and  line) 

LF  . .  LF  to  show  empty  lines  (always  after  one  of  the 

preceding  combinations) . 

The  other  control  characters  or  the  above  control  characters  in 
different  combinations  may  be  used  but  have  no  guaranteed  effect. 

The  character  Delete  may  occur  but  has  no  guaranteed  effect.  The 
IA5String  in  a  P2  IA5Text  BodyPart  represents  a  series  of  lines 
which  may  be  divided  into  pages.     Each  line  should  contain  from  0 
to  80  graphic  characters  for  guaranteed  rendition.     Longer  lines 
may  be  arbitrarily  broken  for  rendition.     Note  that  X.408  states 
that  for  conversion  from  IA5Text  to  Teletex,  the  maximum  line 
length  is  77  characters. 

7.13.2  GENERATING  AND  IMAGING  T61 String 
For  further  study. 
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7.14  APPENDIX  D:     DIFFERENCES  IN  INTERPRETATION  DISCOVERED  THROUGH 
TESTING  OF  THE  MHS  FOR  THE  CeBlt  87  DEMONSTRATION 

Several  interworking  problems  were  discovered  through  mult i -vendor 
testing.     These  problems,  and  recommendations  for  solutions  to  them 
are  discussed  in  this  appendix. 


7.14.1       ENCODING  OF  RTS  USER  DATA 

The  password  is  defined  as  an  ANY  in  the  X.400  Recommendations, 
and  implementor ' s  groups  have  decided  to  use  an  lASString  for 
this  field.     There  was  some  confusion  about  what  the  X.409 
encoding  for  this  lASString  would  be,  and  the  correct  encoding 
is : 

class:       context  specific 
form:  constructor 
id  code :  1 

length:     length  of  contents 
contents:         (primitive  encoding) 
lASString:  16 

length:  length  of  contents 

contents:  the  password  string 

class:      context  specific 
form:  constructor 
id  code :  1 

length:     length  of  contents 

contents:         (constructor  encoding)   left  as  an  exercise  for  the 
reader 

Implementations  should  be  prepared  to  receive  any  X.409  type  for 
the  password  because  of  its  definition  as  an  ANY. 


7. 14.2      EXTRA  SESSION  FUNCTIONAL  UNITS 

One  vendor  proposed  more  than  the  required  set  of  functional 
units  on  opening  the  session  connection,  and  the  receiver 
rejected  the  connection.     All  debate  aside  about  whether  the 
initiator  should  have  proposed  units  outside  of  the  required  set, 
or  whether  the  receiver  should  have  rejected  the  connection,  the 
set  of  functional  units  can  be  negotiated  in  a  straightforward 
way.     The  following  is  recommended. 

If  the  initiator  proposes  using  more  than  the  required  set  of 
functional  units,  the  responder  should  specify  the  set  of 
functional  units  that  it  would  like  to  use  (which  should  include 
the  required  set)  in  the  open  response.     The  session 
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implementations  will  automatically  use  the  intersection  of  the 
units  proposed  by  both  sides. 

If  the  initiator  proposes  using  less  than  the  required  set  of 
functional  units,   the  responder  should  reject  the  connection. 
Unfortunately,  there  is  not  an  appropriate  RefuseReason  for 
rejecting  the  connection,   so  instead  of  refusing  the  connection 
in  the  response  to  the  S- CONNECT,  the  receiver  should  issue  an  S 
U-ABORT  with  an  AbortReason  of  protocolError .     Note  that  it  is 
valid  to  issue  an  S-U-ABORT  instead  of  responding  to  the  S- 
CONNECT.     A  problem  report  has  been  submitted  to  the  CCITT 
requesting  the  addition  of  a  RefuseReason  for  this  situation. 

If  the  responder  proposes  using  less  than  the  required  set  of 
functional  units,   the  session  connection  is  established  before 
the  initiator  can  check  for  this.     If  too  few  functional  units 
have  been  proposed,   the  initiator  should  abort  the  connection 
using  S-U-ABORT,  with  an  abort  reason  of  protocolError. 

7 . 14. 3  MIXED  CASE  IN  THE  MTA  NAME 

The  MTA  name  is  frequently  exchanged  over  the  telephone  when  two 
systems  are  being  configured  to  communicate  with  one  another.  I 
one  such  telephone  exchange,   the  casing  of  the  MTA  name  was  not 
specified,   the  MTA  name  consisted  of  both  upper  and  lower  case 
letters,   and  one  of  the  implementations  compared  MTA  names  for 
equality  in  a  case  sensitive  manner.     Consequently,  connections 
failed  until  the  problem  was  detected  and  repaired.     It  is 
recommended  that  the  MTA  name  be  compared  for  equality  in  a  case 
insensitive  manner,  and  that  the  password  be  compared  for 
equality  in  a  case  sensitive  manner. 

7. 14.4  X.410  ACTIVITY  IDENTIFIER 

The  X.400  Implementor ' s  Guide  recommends  that  the  activity 
identifier  be  X.409  encoded,  but  this  is  only  a  recommendation 
and  not  a  requirement.     Consequently,  receiving  systems  cannot 
assume  that  the  activity  identifier  will  be  X.409  encoded. 

7.14.5  ENCODING  OF  PER  RECIPIENT  FLAG  AND  PER  MESSAGE  FLAG 

In  the  definition  of  the  PerRecipientFlag  in  X.411,   there  is  a 
statement  that  the  last  three  bits  are  reserved,  and  should  be 
set  to  zero.     It  is  unclear  whether  those  bits  are  unused  in  the 
X.409  encoding.     Receivers  should  accept  encodings  with  either 
zero  or  three  unused  bits.     A  problem  report  has  been  submitted 
to  the  CCITT  asking  for  clarification. 
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Though  there  is  not  any  statement  in  X.411  about  the  last  four 
bits  of  the  PerMessageFlag ,  some  vendors  have  encoded  this  with 
zero  unused  bits,  and  some  have  encoded  it  with  four  unused  bits. 
The  PerMessageFlag  should  be  encoded  with  at  least  four  unused 
bits . 


7 ■ 14. 6       ENCODING  OF  EMPTY  BITSTRINGS 

There  are  three  valid  encodings  for  an  empty  bitstring:  a 
constructor  of  length  zero,  a  constructor  of  indefinite  length 
followed  by  the  end-of -contents  terminator,  and  a  primitive  of 
length  one  with  a  zero  octet  as  the  value. 

7.14.7  ADDITIONAL  OCTETS  FOR  BITSTRINGS 

Nothing  in  X.409  constrains  an  implementation  from  sending  two, 
three,   four,  or  even  more  octets  for  a  bitstring  that  fits  into 
one  octet,  with  the  undefined  bits  set  to  zero.     Note  that  the 
number  of  excess  octets  is  bounded  by  the  pragmatic  constraints 
guidelines  of  the  CCITT  X.400  Implementor ' s  Guide  for  all  of  the 
bitstrings  in  PI. 

7.14.8  APPLICATION  PROTOCOL  IDENTIFIER 

If  a  value  other  that  1  is  received  in  the  applicationProtocol  of 
the     pUserData  in  the  PConnect,  NIST  implementations  will  reject 
the  connection.     If  CEN/CENELEC  implementations  receive  a  value 
other  than  8883  for  this  field,   they  will  reject  the  connection. 
This  is  an  unfortunate  state  of  affairs,  because  if  NIST 
implementations  accept  the  value  of  8883  without  supporting  the 
MOTIS  service  elements,   they  would  be  misrepresenting  themselves. 
To  make  matters  worse,  CEPT  uses  a  value  of  1,  but  relays  MOTIS 
elements,  which  means  that  MOTIS  elements  will  be  relayed  to 
implementations  using  a  value  of  1  to  demonstrate  that  they  do 
not  support  MOTIS.     Work  is  continuing  to  try  to  find  a  solution 
that  will  allow  European  implementations  to  interwork  with  U.S 
implementations. 

7.14.9  INITIAL  SERIAL  NUMBER  IN  S- CONNECT 

This  should  be  implemented  in  accordance  with  section  3.5.1  E4  of 
the  Implementors '  Guide. 
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7 ■ 14. 10     CONNECTION  DATA  ON  RTS  RECOVERY 

It  is  clarified  that  the  ConnectionData  is  identical  in  both  the 
S -CONNECT. request  and  the  S -CONNECT . response .     The  value  of  the 
ConnectionData  is  the  old  Session  Connection  Identifier. 

7.14.11     ACTIVITY  RESUME 

If  an  activity  is  being  resumed  on  a  new  session  connection,  it 
is  not  clear  from  X.410  and  X.225  whether  all  four  of  the  called- 
ss-user  reference,   the  calling-ss-user  reference,   the  common 
reference,  and  the  additional  reference  information  should  be 
specified  in  the  S -ACTIVITY-RESUME,  or  whether  one  of  the  ss- 
user-references  should  be  absent.     It  is  also  unclear  whether  the 
called-ss-user  reference  should  be  identical  to  the  calling-ss- 
user  reference  if  both  are  present.     Consequently,  receivers 
should  be  tolerant  of  this  situation.     Appropriate  problem 
reports  will  be  submitted  to  the  CCITT  asking  for  clarification. 


7. 14. 12  OLD  ACTIVITY  IDENTIFIER 

The  Old  Activity  Identifier  in  S -ACTIVITY-RESUME  refers  to  the 
original  activity  identifier. 

7.14.13  NEGOTIATION  DOWN  TO  TRANSPORT  CLASS  0 

For  European  implementations,  X.410  specifies  that  class  0 
transport  must  be  supported.     However,   it  is  permissible  for  an 
initiator  to  propose  a  higher  class  as  the  preferred  class, 
provided  that  class  0  appears  as  the  alternate  class  in  the  T- 
Connect  PDU.     A  responding  implementation  can  choose  to  use 
either  the  preferred  or  alternate  class,  but  again,  must  be  able 
to  use  class  0.     In  other  words,  for  private  to  private 
connections  in  Europe,  class  0  transport  is  required. 

This  conflicts  with  the  NIST  agreements,  since  class  0  is  only 
required  if  one  of  the  partners  in  a  connection  is  an  ADMD. 
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7.15        APPENDIX  E:     WORLDWIDE  X.400  CONFOI^ANCE  PROFILE  MATRIX 


Y  CONFORMANCE  (E) 

implies  a  conformance  problem  for  European  products  in  the  United  States. 

Y  CONFORMANCE  (US) 

implies  a  conformance  problem  for  U.S.  products  in  Europe. 

o       The  A/311  profile  is  specified  in  Env  41  202,  the  A/3211  profile 
in  Env  41  201 

o        No  TTC  protocol  classification  for  RTS  exists. 

o        The  notation  XA  indicates  "X"  for  PRMDs  and  "Y"  for  ADMDs, 
i.e.,   "M/G"  would  be  Mandatory  for  PRMDs  and  Generatable  for 
ADMDs. 
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Table  7E.1.     Protocol  element  comparison  of  RTS 


RTS  element 

NIST 

A/311 

A/3211 

PROBLEM  Y/N 

PConnect 

M 

M 

M 

N 

DataTrans  fer Syntax 

M  0 

M  0 

M  0 

N 

PUserData 

M 

M 

M 

N 

checkpoints ize 

H 

H 

H 

N 

windows ize 

H 

H 

H 

N 

dialogueMode 

H 

H 

H 

N 

connectdata 

M 

M 

M 

N 

applicationProtocol 

G  1 

H  1 

R  8883 

N 

H  8883 

Connect ionData 

Open 

G 

G 

G 

N 

Recover 

G 

H 

G 

N 

Open 

RTSUserData 

G 

G 

G 

N 

Recover 

SessionConnectionID 

G 

G 

G 

N 

RTSUserData 

MTAName 

G 

G 

G 

N 

Password 

G 

G 

G 

N 

null 

G 

G 

G 

N 

SessionConnectionID 

CallingUserRef erence 

M 

M 

M 

N 

CommonRef erence 

M 

M 

M 

N 

Addi  t  ionalRe  f Inf o 

H 

H 

H 

N 

PAccept 

G 

G 

G 

N 

DataTrans ferSyntax 

M  0 

M  0 

M  0 

N 

(Continued  on  next  page.) 
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Table  7E,1.     Protocol  element  comparison  of  RTS ,  continued 


RTS  element 

NIST 

A/311 

A/3211 

PROBLEM  (Y/N) 

PUserData 

M 

M 

M 

N 

Checkpoints ize 

H 

H 

H 

N 

Windows ize 

H 

H 

H 

N 

Connec tionData 

M 

TV7 
N 

PRefuse 

G 

G 

G 

N 

RefuseReason 

M 

M 

M 

N 

SSUserData 

G 

G 

G 

N 

(in  S- TOKEN -PLEASE) 

Abortlnformation 

G 

G 

G 

N 

(in  S-U-ABORT) 

AbortReason 

H 

H 

H 

N 

ref lectedParameter 

X 

X 

X 

N 
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Table  7E.2.     Protocol  element  comparison  of  PI 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

ORnarae 

S  tandardAt tr ibuteLls  t 

M 

M 

M 

M 

N  See  Note  4 

DomainDefAttributeList 

X 

X 

X 

G 

Y  See  Note  5 

StandardAttributeList 

CountryName 

R 

R 

R 

M 

N 

ISO  R 

R 

N 

X.121  H 

H 

Y  Conformance  (E) 

Other  X 

X 

Y  Prot  Vio 

AdrainistrationDoraainName 

R 

R 

G 

M 

N 

...  if  PrintableString 

R 

G 

N 

...  if  numericString 

H 

H 

Y  Conformance  (E) 

X.121  Address 

X 

X/R 

X 

Y  Conf(US)See  Note  1 

Terminal  ID 

X 

X/G 

X 

Y  Conf(US)See  Note  1 

PrivateDomainName 

G 

G 

G 

G 

N 

OrganizationName 

G 

G 

G 

G 

N 

UniqueUAidentif ier 

X 

X/G 

X 

Y  Conf(US)See  Note  1 

PersonalName 

G 

G 

G 

G 

N 

OrganizationalUnit 

G 

G 

G 

G 

N 

DoraainDefinedAt tribute 

X 

X 

X 

G 

N 

Type 

M 

M 

M 

M 

N 

Value 

M 

M 

M 

M 

N 

PersonalName 

Surname 

M 

M 

M 

M 

N 

GivenName 

G 

G 

G 

G 

N 

Initials 

G 

G 

G 

G 

N 

GenerationQualif ier 

G 

X 

X 

X 

Y  Conformance  (E) 

GlobalDomainldentif ier 

CountryName 

M 

M 

n 

M 

M 

N 

AdministrationDomainName 

M 

M 

G 

M 

Y  Proto  Vio 

PrivateDomainldentif ier 

R/H 

H 

R 

M/X 

N 

MPDU 

UserMPDU 

G 

G 

G 

G 

Y  TTC  required 

MPDU  size  is 

32K 

DeliveryReportMPDU 

G 

G 

G 

G 

N 

ProbeMPDU 

H 

H 

H 

H 

N 
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Table  7E.2.     Protocol  element  comparison  of  PI,  continued 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

UserMPDU 

UMPDUenvelope 

M 

M 

M 

M 

N 

UMPDUcontent 

M 

M 

M 

M 

N 

UMPDUenvelope 

MPDUidentifier 

M 

M 

M 

M 

N 

origlnatorORname 

M 

M 

M 

M 

N 

originalEncodedTypes 

G 

H 

H 

G 

Y  Conformance 

(E) 

ContentType 

M 

M 

M 

M 

N 

UAcontentID 

H 

H 

H 

H 

N 

Priority 

u 

\j 

(j 

N 

PerMessageFlag 

G 

G 

G 

G 

N 

De  f er redDe 1 ive  ry 

X 

X 

X 

X 

N 

PerDoraainBilatlnfo 

X 

X 

X 

X 

N 

Recipientlnfo 

M 

M 

M 

M 

Y  TTC  MPDU  32K 

Tracelnformation 

M 

M 

M 

M 

N 

MOTIS 

-> 

LatestDe livery 

X 

N 

MOTIS 

-> 

InternalTracelnfo 

M/P 

P 

N 

UMPDUcontent 

M 

M 

M 

M 

N 

MPDUidentifier 

GlobalDomainldent 

M 

M 

M 

M 

N 

lASstring 

M 

M 

M 

M 

N 

PerMessageFlag 

DiscloseRecipients 

H 

C  B  MTT 

H 

Y  Conformance 

(US) 

H  at  UA 

? 

Y  Conformance 

(US) 

ConversionProhibited 

G 

G 

G 

G 

N 

AlternatRecipAl lowed 

H 

G  @  MTL 

H 

X 

Y  Conformance 

(US) 

H  at  UA 

? 

Y  Conformance 

(US) 

ContentRe  turnReque  s  t 

X 

X 

X 

X 

MOTIS 

-> 

redirectionProhibited 

X 

N 

PerDomainBilaterallnfo 

CountryName 

M 

M 

M 

M 

N 

AdminDomainName 

M 

M 

G 

M 

Y  Prot  Vio 

MOTIS 

-> 

PrivateDoraainName 

G 

N 

Bilaterallnfo 

M 

M 

M 

M 

N 

(Continued  on  next  page 
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Table  7E.2.     Protocol  element  comparison  of  PI,  continued 


PI  Protocol 

IN  lb  1 

A  /n  1 

A/  J  i  i 

A/  J  Z  J.  1 

PPORT  PM  /'Y/Kf^ 

Delive ryReportContent 

original  MPDUident 

n 

n 

M 

n 

JN 

intermediate  Trace 

A/  Vj 

Y 
A 

Y 

A 

Y 

A 

UAcontentiu 

G 

G 

G 

G 

N 

ReportedRecipientInf o 

M 

M 

M 

M 

Y  TTC  256  max 

returned 

u 
n 

u 
n 

Y 
A 

Y 
A 

1    ocelli.  U  L  JlldllC  c 

billing  information 

V 
A 

Y 
A 

Y 
A 

Y 
A 

IN 

ReportedRecip lent Info 

recipient  ORname 

M 

M 

n 

M 

rl 

M 

n 

M 
IN 

extensions Identifier 

M 

M 

M 

M 

M 

N 

PerRecipientFlag 

M 

M 

M 

M 

M 

IN 

Las tTr ace Information 

M 

M 

M 

M 

N 

intendedRecipient 

H 

H 

H 

H 

N 

Supplementary Info 

A/  n 

Y 
A 

Y 
A 

Y 
A 

MOTIS-> 

Reassignment Info 

X 

N 

MOTIS -> 

Reassignmentlnfo 

MOTIS -> 

intendedRecipient 

M 

N 

MOTIS -> 

reasonForReassignment 

u 
n 

M 

Las tTrace Information 

arrival 

M 

M 

M 

M 

N 

convertedEnc Info Types 

u 
n 

Y  Conformance  (E) 

Report 

M 

M 

M 

n 

M 
IN 

Report 

Deliveredinf o 

G 

G 

G 

1-M 

N  See  Note  6 

NonDe liver edinfo 

n 
\j 

n 
\j 

r; 

N 

Deliveredlnfo 

delivery 

M 

M 

M 

M 

N 

TypeofUA 

R/H 

H 

R 

M/G 

N 

NonDe 1 ive  r edinfo 

ReasonCode 

M 

M 

M 

M 

N 

DiagnosticCode 

H 

H 

H 

H 

N 

MOTIS -> 

UAprofile Identifier 

X 

N 

MOTIS -> 

UAprofile Identifier 

MOTIS -> 

ContentType 

M 

N 

MOTIS -> 

EncodedlnfoTypes 

M 

N 

(Concinued  on  next  pag 
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Table  7E.2.     Protocol  element  comparison  of  PI,  continued 


PI  Prn^r^rr^^ 

i.  ±      L  1.  \J  \^\J\^\J 

IN  1 0  i 

A        1  1 
A/  J  LI 

A  /T  0  1  1 

TTT' 

■DDAT3T  VM     /V  /M  ^ 

rK(JDL,ilrl  (,1/IN_) 

ProbeEnvelope 

probe 

M 

M 

M 

M 

IN 

M 

M 

M 

M 

NT 

^-«  u  11  uc  n  L.  X  y  p  e 

M 

n 

rl 

rl 

n. 

IN 

UArontpnt"Tn 

H 
n 

u 
ii 

yjL  i.gi.iLaxJiiiic xnx u  1  ypes 

u 
n 

u 
rl 

Y  Conformance  (E) 

TTflppTn'Fn'rTnflt"'!  on 

M 

M 

M 

M 

PerMessageFlag 

G 

G 

G 

G 

N 

ContentLength 

H 

H 

H 

H 

N 

X 

X 

X 

Y 

N 

w       X  L/  X  C  &  1  \v  X  L  ft  A>  V 

M 

M 

M 

M 

Y  TTT  mpy 

MOTIS->       InternalTraceTnf o 

M/P 

p 

N 

Recipientlnfo 

RecipientORname 

M 

M 

M 

M 

N 

Extensionldentif ier 

M 

M 

M 

M 

N 

X  C2 X IvcL. Xp  XCILL-x  Xclg 

M 

M 

M 

M 

M 

ExplicitConversion 

X 

X 

X 

X 

N 

MOTIS ->  OriginatorReqAlternatRecip 

X 

N 

MOTIS->  Reassignmentlnfo 

X 

N 

PerRecipientFlag 

ResponsibilityFlag 

M 

M 

M 

M 

N 

ReportRequest 

M 

M 

M 

M 

N 

UserReportRequest 

M 

M 

M 

M 

N 

Tracelnformation 

GlobalDomainldent 

M 

M 

M 

M 

N 

DomainSuppliedlnfo 

M 

M 

M 

M 

N 

(Continued  on  next  page 
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Table  7E.2.     Protocol  element  comparison  of  PI,  continued 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

DomainSuppliedlnfo 

arrival 

M 

M 

M 

M 

N 

deferred 

X 

X 

X 

X 

N 

action 

M 

M 

M 

M 

N 

(0=relayed) 

G 

G 

G 

N  Note: 

Re-routing  not 

required. 

(l=rerouted) 

H 

H 

H 

N 

MOTIS->  (2=recipientReassigned) 

H 

N 

converted 

H 

G 

H 

H 

Y  Conformance (US) 

previous 

H 

G 

G 

X 

Y  Conformance (US) 

(Note:  G  is 

inconsistent  with 

action  (relayed) 

being  "H.") 

ORname 

EncodedlnforraationTypes 

BitString 

M 

M 

M 

M 

N    See  Note  3 

G3NonBasicParameters 

X 

X 

X 

X 

N 

Te le texNonBas icParams 

X 

R 

X 

X 

Y  Conformance (US) 

PresentationAbilities 

X 

X 

X 

X 

N 

DeliveryReportMPDU 

G 

G 

M 

G 

N 

DeliveryReportEnvelop 

M 

M 

M 

M 

N 

De 1 i ve ryRepor tContent 

M 

M 

M 

M 

N 

DeliveryReportEnvelope 

report 

M 

M 

M 

M 

N 

originator  ORname 

M 

M 

M 

M 

N 

Tracelnforraation 

M 

M 

M 

M 

N 

InternalTracelnfo 

M/P 

P 

N 

(Continued  on  next  page 
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Table  7E.3.     Protocol  element  comparison  of  P2 


P2  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

UAPDU 

IM  UAPDU 

G 

G 

G 

G 

N 

SR_UAPDU 

X 

X 

X 

X 

N 

IM_UAPDU 

Heading 

M 

M 

M 

M 

N 

Body 

M 

M 

M 

M 

N 

Heading 

IPmessagelD 

M 

M 

M 

M 

N 

Originator  ORname 

R 

R 

R 

M/G 

N 

AuthorizingUsers 

H 

H 

H 

H 

Y  TTC  16  max 

PrimaryRecipients 

G 

G 

G 

G 

Y  TTC  256  max 

CopyRecipients 

G 

G 

G 

G 

Y  TTC  256  max 

u 
n 

u 
n 

u 
n 

u 
n 

V   TTP    9SA  mav 

1   iiv>  max 

InReplyTo 

G 

G 

G 

G 

N 

Obsoletes 

H 

H 

H 

H 

Y  TTC  8  max 

CrossReferences 

H 

H 

H 

H 

Y  TTC  8  max 

tJ  \JLU     1    &  W  \-r 

G 

G 

G 

G 

N 

ExpiryDate 

H 

H 

H 

H 

N 

ReplyBy 

H 

H 

H 

H 

N 

£\.cp i.y  LiJU^Ki L  ^ 

u 
n 

u 
n 

u 
n 

u 
n 

Importance 

H 

H 

H 

H 

N 

Sensitivity 

H 

H 

H 

H 

N 

All  f~n  'Fm'xjfl  Trip  (\ 

H 

H 

H 

N 

MOTIS->  CirculationList 

X 

N 

MOTIS->  ObsoletingTime 

X 

N 

IPmessagelD 

ORname 

H 

H 

H 

H 

N 

PrintableString 

M 

M 

M 

M 

N 

ORdescriptor 

ORname 

H 

H 

H 

N  See  Note  6 

FreeFormName 

H 

H 

H 

> 

N 

TelephoneNumber 

H 

H 

H 

G 

N 

Recipient 

ORdescriptor 

M 

M 

M 

M 

N 

ReportRequest 

X 

X 

X 

X 

N 

ReplyRequest 

H 

H 

H 

H 

N 

(Continued  on  next  page 
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Table  7E.3.     Protocol  element  comparison  of  P2 ,  continued 


P2  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  CY/N) 

MOTIS-> 

CirculationList 

MOTIS-> 

CirculationMember 

X 

N 

MOTIS-> 

checkmark 

M 

N 

MOTIS-> 

membername 

M 

N 

MOTIS-> 

OBsoletingTirae 

lL\J  L  ±  O  ^ 

i.  J.  me 

H 

N 

MOTIS-> 

IP_MessageID 

H 

N 

Body 

BodyPart 

G 

M 

M 

G 

Y  Conformance  (US) 

SR_UAPDU 

NonReceipt 

H 

H 

H 

N 

Receipt 

H 

H 

H 

h 
_j 

N 

l<  O           T*  ^  O  /I 

M 

M 

M 

M 

N 

ActualRecipient 

R 

R 

R 

G 

N 

IntendedRecipient 

H 

H 

H 

H 

N 

Converted 

X 

X 

X 

G 

N 

MOTIS-> 

CirculationStatus 

X 

N 

NonReceiptlnformation 

Reason 

M 

M 

M 

M 

N 

NonRece iptQual if ier 

H 

H 

H 

H 

N 

=expired  (value) 

0 

0 

0 

0 

N 

=obsoleted  (value) 

1 

1 

1 

1 

N 

=subscriptionTerminated 

2 

2 

2 

2 

N 

MOTIS-> 

=timeobsoleted  (value) 

X 

N 

Comments 

H 

H 

H 

X 

N 

returned 

H 

X 

X 

X 

Y  Conformance  (E) 

Receipt Information 

Receipt 

M 

M 

M 

M 

N 

TypeOfReceipt 

H 

H 

H 

G 

N 

Supplementary Info 

X 

X 

X 

X 

N 

(Continued  on  next  pa 


7-94 


December  '89 


Table  7E.3.     Protocol  element  comparison  of  P2 ,  continued 


P2  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

BODYPART  SUPPORT 

o  IA5  Text 

G 

G 

G 

N  See  Note  7 

o  TLX 

X 

X 

X 

N 

o  Voice 

X 

X 

X 

N 

o  G3FAX 

X 

X 

X 

N 

o  TIFO 

X 

X 

X 

N 

o  TTX 

X 

X/H 

X 

Y  Conf(US)See  Note  2 

o  VideoTex 

X 

X 

X 

N 

o  NationallyDef ined 

X 

X 

X 

N 

o  Encrypted 

X 

X 

X 

N 

o  ForwardedlPmessage 

H 

H 

H 

N 

o  SFD 

X 

X 

X 

N 

o  TIFI 

X 

X 

X 

N 

MOTIS->  o  ODA 

X 

N 

MOTIS->  o  IS06937  Text 

H 

N 
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Note  1:  It  should  be  noted  that  the  A/311  profile  states:  For  routing 
all  ADMDs  should  support  all  Form  1  Variants  of  0/R  Name.  All 
PRMDs  should  support  at  least  Form  1,  Variant  1  form  of  OR  Name. 

Note  2:  It  should  also  be  noted  that  the  A/311  profile  requires  that  all 
ADMDs  should  support  the  reception  of  Teletex  body  parts  for 
delivery  to  their  own  UAEs . 

Note  3:  An  A/3211  implementation  may  generate  MOTIS  encoded  information 
types.     See  7.6.11. 

Note  4:  Only  Form  1  Variant  1  of  0/Rname  shown  for  TTC ,  but  TTC  defines 
other  forms  and  variants .  Form  1  Variant  1  recommended  for  PRMDs 
and  ADMDs,  Form  1  Variant  2  also  recommended  for  ADMDs. 

Note  5:  DDA's  can  be  used  to  specify  recipients  in  any  Japanese  domains 
other  than  TTC,  Assignment  of  DDAs  for  UAs  within  TTC  domains  is 
not  recommended. 


Note  6:  One  of  [Deliveredlnfo/NonDeliveredlnfo]  must  be  present.  TTC 
encodes  this  as  shown.  Other  profiles  represent  this  by 
classifying  both  protocol  elements  as  generatable.  A  similar 
situation  exists  with  the  P2  ORdescriptor . 

Note  7:  TTC  is  expected  to  support  IA5  for  some  international  MHS 
communications . 
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7.16  APPENDIX  F:     INTERWORKING  WARNINGS 

ADMD  name  is  to  be  encoded  as  a  single  space  when  configurations  with 
no  ADMD's  are    present.     It  should  be  noted  that  this  may  change  in 
January  1988  so  that  the  ADMD  name  is  encoded  as  a  zero  length  element 
in  such  cases. 

The  NIST  agreements  allow  implementation  to  generate  MPDUs  with  no 
body  parts.     Such  MPDUs  will  be  rejected  by  European- conformant 
systems.     (Note  this  situation  may  change  in  January  1988) 

In  order  to  optimize  the  number  of  recipients  you  can  read  and  reply 
to,  it  is  advisable  to  be  able  to  generate  all  standard  0/R  name 
attributes . 
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MESSAGE  HANDLING  SYSTEMS 
8.1  INTRODUCTION 

This  is  an  Implementation  Agreement  developed  by  the  Implementor ' s 
Workshop  sponsored  by  the  National  Institute  of  Standards  and 
Technology  to  promote  the  useful  exchange  of  data  between  devices 
manufactured  by  different  vendors.  This  Agreement  is  based  on,  and 
employs  protocols  developed  in  accord  with,  the  OSI  Reference  Model. 
It  provides  detailed  guidance  for  the  implementor  and  eliminates 
ambiguities  in  interpretations. 

This  is  an  Implementation  Agreement  for  Message  Handling  Systems  (MHS) 
based  on  both  the  CCITT  X. 400 (1988)  series  of  Recommendations  and  the 
similar  (but  not  identical)  ISO  MOTIS  standard  (see  References) .  The 
term  'MHS'  is  used  to  refer  to  both  sources  where  a  distinction  is 
unnecessary.  Similarly,  '1984'  and  '1988'  are  often  used  to 
distinguish  between  the  CCITT  X. 400(1984)  series  of  Recommendations 
and  the  later  sources. 

This  Implementation  Agreement  seeks  to  establish  a  common 
specification  which  is  conformant  with  both  CCITT  and  ISO  with  a  view 
to: 

o  Preventing  a  proliferation  of  incompatible  communities  of  MHS 
systems  which  are  isolated  for  protocol  reasons, 

o  Achieving  interworking  with  implementations  conforming  to  the 
NIST  Stable  Implementation  Agreements  for  CCITT  1984  X.400-based 
Message  Handling  Systems,  and 

o  Facilitating  integration  of  other  OSI-based  services  (e.g., 
Directory)  within  a  single  real  system. 

This  initial  Implementation  Agreement  is  designed  to  encourage  early 
upgrade  of  existing  1984-based  systems  as  follows: 

o  To  add  1988  functionality  (Message  Store,  remote  User  Agent, 
etc) ,  and 

o  To  provide  a  minimal  conformant  1988  MHS  as  a  firm  basis  for  the 
introduction  of  further  1988  services  and  features.  Subsequent 
versions  of  this  Agreement  will  define  such  additional  1988 
aspects  as  incremental  enhancements. 

However,  it  is  considered  that  the  NIST  Stable  Implementation 
Agreements  for  CCITT  1984  X.400-based  Message  Handling  Systems  (ch.  7) 
should  not  be  withdrawn  at  this  stage.  It  is  anticipated  that 
X. 400 (1984)     implementations     will     continue     to     provide     a  viable 
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alternative  for  applications  that  do  not  require  the  additional  1988 
functionality  for  some  time. 

8.2  SCOPE 

This  Agreement  specifies  the  requirements  for  MHS  implementations 
based  on  the  1988  MHS  standards. 

This  Agreement  applies  equally  to  Private  Management  Domains  (PRMDs) 
and  Administration  Management  Domains  (ADMDs) .  Four  boundary 
interfaces  are  specified,  as  illustrated  in  figure  8.1: 

o  Management  Domain  (MD)  to  MD, 

o  Message  Transfer  Agent  (MTA)  to  MTA  within  a  domain, 

o  MTA  to  remote  Message  Store  (MS)  or  User  Agent  (UA) ,  and 

o  MS  to  remote  UA. 

MHS  protocols  other  than  the  Message  Transfer  Protocol  (PI),  the 
Message  Transfer  System  Access  Protocol  (P3),  the  Interpersonal 
Messaging  Protocol  (P2) ,  and  the  Message  Store  Access  Protocol  (P7) 
are  beyond  the  scope  of  this  Agreement.  Issues  arising  from  the  use 
of  other  protocols  are  outside  the  scope  of  this  document.  This 
Agreement  describes  the  services  provided  at  each  interface  shown  in 
figure  8.1. 

MHS  implementations  may  be  configured  as  any  single  or  multiple 
occurrence  or  combination  of  MTA,  MS  and  UA,  as  illustrated  in  figure 
8.1.  It  is  not  intended  to  restrict  the  types  of  system  that  may  be 
configured  for  conformance  to  this  Agreement  (although  it  is  equally 
recognized  that  not  all  configuration  types  may  be  commercially 
viable) . 
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Figure  8.1.     Scenario  Definition. 


The  1988  MHS  standards  cover  a  wide  and  diverse  range  of  functional  areas, 
not  all  of  which  would  be  relevant  to  every  implementation.  In  order  to 
achieve  a  more  precise  definition  of  conformance  requirements  according  to 
the  functionality  supported  by  an  implementation,  and  additionally  to 
facilitate  future  enhancement  of  this  initial  specification,  the  concept  of 
'Functional  Groups'  has  been  introduced.  Figure  8.2  shows  the  Functional 
Groups  covered  by  this  Agreement  and  indicates  where  they  are  defined  in 
this  chapter.  Conformance  requirements  for  support  of  Functional  Groups  by 
particular  configurations  are  specified  in  section  8.16. 

In  the  context  of  these  agreements,  the  term  "Support"  means  that  the 
service  provider  makes  the  element  of  service  (and  related  elements  of 
protocol)  available  to  the  service  user.  The  service  user  provides  adequate 
access  to  invoke  the  elements  of  service  and/or  makes  information  associated 
with  the  service  element  available.  Additionally,  for  "Not  Defined"  or  "Not 
Applicable"  elements,  the  service  provider  is  not  required  to  make  the 
element  available  to  the  service  user.  However,  the  service  provider  should 
not  regard  the  occurrence  of  the  corresponding  protocol  elements  as  an  error 
and  should  relay  those  elements.  Naturally,  protocol  elements  marked 
critical  for  transfer  must  be  processed  per-X-;400  se^-iea"  according  to  the 
base  standards. 
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The  following  functional  groups  are  covered  by  this  Implementors  Agreement: 

a)  The  MT  Kernel  in  clause  5; 

b)  The  IPM  Kernel  in  clause  6; 

c)  The  Message  Store  in  clause  7; 

d)  Remote  User  Agent  support  in  clause  8; 

e)  Distribution  Lists  in  clause  9.2  (which  are  for  further  study); 

f)  Use  of  Directory  in  clause  9.3; 

g)  MHS  Management  in  clause  10  (which  is  for  further  study) ; 

h)  Security  in  clause  11; 

i)  The   Physical   Delivery  Access  Unit   in  clause   12.1    (which   is  for 
further  study) ; 

j)  Other  Access  Units  in  clause  12.2  (which  are  for  further  study); 

k)  Conversion  in  clause  13  (which  is  for  further  study) ; 

1)  Redirection  in  clause  14  (which  is  for  further  study) ;  and, 

m)  The    EDI   Messaging   Service    in   clause    15    (which    is    for  further 
study) . 
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MT  Kernel 
(8.5) 


IPM  Kernel 
(8.6) 


Message  Store 
(8.7) 


Remote  User 
Agent  Support 
(8.8) 


Use  of  Directory 
(*) 

(8.9.3) 


Distribution 
Lists  (*) 
(8.9.2) 


Security  (*) 
(8.11) 


Physical 
Delivery  (*) 
(8.12.1) 


Other  Access 
Units  (*) 
(8.12.2) 


Conversion  (*) 
(8.13) 


(  *  -  for  further 
study  ) 


Figure  8.2.     MHS  Functional  Groups 
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8.3  STATUS 


This  version  of  the  Implementation  Agreements  for  Message  Handling 
Systems  (MHS)  is  under  development.  It  is  based  on  the  CCITT 
X. 400(1988)  Recommendations  and  ISO  MOTIS  (10021,  parts  1-7) 
standards . 

It  is  intended  that  the  Stable  Implementation  Agreements  will 
initially  include  an  Agreement  which  specifies  a  minimal  1988-based 
MHS  implementation  and  support  for  Message  Stores  and  remote  User 
Agents,  and  which  addresses  interworking  with  1984-based 
implementations.  The  remaining  features  specified  in  the  1988 
standards  will  be  covered  in  subsequent  versions  of  this  Agreement. 

This  initial  version  has  not  yet  been  aligned  with  other  MHS  profiles, 
so  changes  may  be  necesary  in  the  future  for  international 
harmonization,  (e.g.,  support  for  international  character  repertoires 
and  conversion.) 

8.4  ERRATA 

I  No -Errata -to -Stable -material: -at -this -feimeT  Alignment  Errata  to  tables 
I        in  sections  8.17.1  to  8.17.3  have  been  included  as  indicated. 


8.5    MT  KERNEL 


8.5.1 


Introduction 


This  section  specifies  the  requirements  for  a  minimal  1988-based 
MTS  implementation  (i.e.,  MTA)  which  is  capable  of  interworking 
with  1984-based  MTAs .  The  'base'  MT  Service  specified  in  this 
section  does  not  include: 


o 


o 


o 


o 


o 


o 


o 


Message  Store  (see  8.7) 
Remote  UA  (see  8.8) 

Use  of  Directory  Services  (see  8.9.3) 
Distribution  Lists  (see  8.9.2) 
Security  (see  8.11) 

Interworking  with  Physical  Delivery  systems  or  Specialized 
Access  (see  8.12) 
Conversion  (see  8.13) 


Such  a  minimal  1988-based  MTA  will  have  the  following 
capabilities  in  order  to  achieve  interworking  with  1984-based 
MTAs  and  to  facilitate  migration  to  full  1988  operation: 


o 


It  will  be  protocol-conformant  to  1988  PI; 
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o  It  will  downgrade  1988  PI  to  1984  PI  when  relaying  to  1984- 
based  MTAs ,  as  specified  in  Annex  B  of  X.419  (see  8.5.5); 

o  It  will  support  both  'normal'  mode  and  'X. 410-1984' 
(' pass through ' )  mode  protocol  stacks  (i.e.,  as  required  by 
ISO  and  CCITT  respectively) . 

8.5.2        Elements  of  Service 

This  section  specifies  the  requirements  for  support  of  MT 
Elements  of  Service  by  an  MTA  conforming  to  the  MT  Kernel 
Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is 
as  follows: 

Mandatory  (M)  -  the  Element  of  Service  must  be  supported  and  made 
available  to  the  service  user; 

Optional  (0)  -  the  Element  of  Service  may  be  supported,  but  is 
not  required  for  conformance  to  this  Agreement; 

Not  Defined/Not  Applicable  (-)  -  the  Element  of  Service  is  not 
defined  by  this  Agreement  or  is  otherwise  not  applicable  in  the 
particular  context; 

To  Be  Determined  (*)  -  the  support  classification  for  the  Element 
of  Service  has  yet  to  be  determined. 

The  requirements  for  support  of  MT  Elements  of  Service  for 
origination  and  reception  and  (where  relevant)  relaying  are 
distinguished.  Elements  of  Service  which  are  new  in  the  1988  MHS 
standards  are  indicated  as  (1988). 

An  MTA  must  support  those  Basic  MT  Elements  of  Service  and  MT 
Optional  User  Facilities  defined  in  clause  19  of  X. 400(1988)  as 
listed  and  qualified  in  tables  8.1  and  8.2  below. 
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Table  8.1.     MT  Kernel:  Basic  MT  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Relaying 

Access  Management 

M^ 

Content  Type  Indication 

M 

M 

Converted  Indication 

M 

M 

M 

Delivery  Time  Stamp  Indication 

M 

Message  Identification 

M 

M 

Non-delivery  Notification 

M 

M 

M 

Original  Encoded  Information 

Types  Indication 

M 

M 

Submission  Time  Stamp  Indication 

M 

M 

User/UA  Capabilities 

Registration  (1988) 

m1 

Notes : 

1)  A  local  matter  in  the  case  of  co- located  UA/MTA  and/or 
MS/MTA  configurations. 
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Table  8.2.     MT  Kernel:  MT  Service  Optional  User  Facilities 


Element  of  Service 

Origination 

Reception 

Relaying 

Alternate  Recipient  Allowed 

M 

0 

- 

Alternate  Recipient  Assignment 

- 

02 

- 

Conversion  Prohibition 

M 

M 

M 

Conversion  Prohibition  in  Case 

of  Loss  of  Information  (1988) 

0 

0 

0 

Deferred  Delivery 

m3 

0 

0 

Deferred  Delivery  Cancellation 

m6 

- 

- 

Delivery  Notification 

M 

M 

- 

Disclosure  of  Other  Recipients 

M 

M 

M 

DL  Expansion  History  Indication 

- 

- 

DL  Expansion  Prohibited 

m5 

- 

- 

Explicit  Conversion 

0 

0 

0 

Grade  of  Delivery  Selection 

M 

M 

M 

Hold  for  Delivery 

- 

M-^ 

- 

Implicit  Conversion 

0 

0 

0 

Latest  Delivery  Designation  (1988 

0 

0 

0 

Multi  Destination  Delivery 

M 

M 

M 

Originator  Requested  Alternate 

Recipient  (1988) 

0 

0 

- 

Prevention  of  Non-delivery 

Notification 

0 

Probe 

M 

M 

M 

Redirection  Disallowed  by 

Originator  (1988) 

0 

0 

Redirection  of  Incoming 

Messages  (1988) 

0 

Requested  Delivery  Method  (1988 

) 

M 

M 

Restricted  Delivery  (1988) 

0 

Return  of  Content 

0 

0 

0 

Notes : 

1)  A  local  matter  in  the  case  of  co- located  UA/MTA  and/or 
MS/MTA  configurations . 

2)  If  Alternate  Recipient  Assignment  is  supported  on 
reception,   then  support  of  Alternate  Recipient  Allowed  is 
Mandatory  on  reception;  otherwise,  support  of  Alternate 
Recipient  Allowed  is  not  applicable  on  reception. 

3)  Support  of  this  MT  Element  of  Service  is  Mandatory  for 
conformance  reasons,  but  may  be  performed  as  a  local 
matter  to  the  originating  MTA. 
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Table  8.2.     MT  Kernel:  MT  Service  Optional  User  Facilities  (Cont.) 


4)  Support  of  this  MT  Element  of  Service  refers  only  to  the 
delivery  of  DL  expansion  history  and  not  to  the  performing 
of  DL  expansion  (see  8.9.2). 

5)  Support  of  this  MT  Element  of  Service  does  not  imply  the 
capability  to  perform  DL  expansion  (see  8,9.3). 

6)  Messages  should  be  held  in  the  originating  MTA  to  provide 
support  for  this  element  of  service. 


8.5.3        MTS  Transfer  Protocol  (Pi) 

The  requirements  for  support  of  MTS  Transfer  Protocol  (PI) 
elements  are  detailed  in  section  8.17.1  (Appendix  A). 

Support  of  MTS  Transfer  Protocol  application  contexts  by  an  MTA 
is  classified  as  in  table  8.3. 


Table  8.3.     Application  Contexts  Classification 


Application  Context 

Support 

mts- transfer -protocol- 1984 
mts- transfer -protocol 
mts- transfer 

Mandatory 
Mandatory 
Mandatory 

Use  of  the  underlying  services  to  support  these  application 
contexts  is  specified  in  section  8.14, 

8.5.4  MTS  -  APDU  Size 
See  Working  Document. 

8.5.5  1988/84  Interworking  Considerations 


See  Working  Document. 
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8.6     IPM  KERNEL 


8.6.1  Introduction 

This  section  specifies  the  requirements  for  a  minimal  1988-based 
IPMS  implementation  (i.e.,  UA)  which  is  capable  of  interworking 
with  1984-based  UAs .  The  'base'  IPM  Service  specified  in  this 
section  does  not  include: 


o  Message  Store  (see  8.7) 

o  Remote  UA  (see  8.8) 

o  Use  of  Directory  Services  (see  8.9.3) 

o  Distribution  Lists  (see  8.9.2) 

o  Security  (see  8.11) 

o  Interworking  with  Physical  Delivery  systems  or  Specialized 
Access  (see  8.12) 

Such  a  minimal  1988-based  UA  will  have  the  following  capabilities 
in  order  to  achieve  interworking  with  1984-based  UAs  and  to 
facilitate  migration  to  full  1988  operation: 

o  It  will  continue  to  support  content  type  P2  (encoded  as 
integer  2)  on  origination  and  reception; 

o        It  will  support  receipt  of  P2  (encoded  as  integer  22) ; 

o  It  may  originate  P2  encoded  as  integer  22 ,  but  the 
guidelines  specified  in  clause  20.2  of  X. 420(1988)  are  to  be 
followed,  i.e.,  the  content  type  shall  be  encoded  as  integer 
2  unless  1988  P2  protocol  elements  are  present. 

All  IPM  UAs  must  support  either  MTS  Submission  and  Delivery  based 
on  the  protocol  classifications  in  section  8.17.3,  or  MS 
Submission  and  Retrieval  based  on  the  protocol  classifications  in 
section  8.17.4.  However,  how  such  information  is  conveyed  to/from 
the  MTS  or  MS  in  the  case  of  a  co- located  UA  is  a  local  matter, 
and  will  not  necessarily  be  subject  to  conformance  verification. 


8.6.2        Elements  of  Service 

This  section  specifies  the  requirements  for  support  of  IPM 
Elements  of  Service  by  a  UA  conforming  to  the  IPM  Kernel 
Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is 
as  defined  in  section  8.5.2. 
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The  requirements  for  support  of  IPM  Elements  of  Service  for 
origination  and  reception  are  distinguished.  Elements  of  Service 
which  are  new  in  the  1988  MHS  standards  are  indicated  as  (1988). 

A  UA  must  support  those  Basic  IPM  Elements  of  Service  and  IPM 
Optional  User  Facilities  defined  in  Clause  19  of  X. 400(1988)  as 
listed  and  qualified  in  tables  8.4  and  8.5  below. 


Table  8.4.     IPM  Kernel:  Basic  IPM  Elements  of  Service 


Element  of  Service 


Grig 


Recep 


Access  Management 
Content  Type  Indication 
Converted  Indication 
Delivery  Time  Stamp  Indication 
IP-message  Identification 
Message  Identification 
Non-delivery  Notification 
Original  Encoded  Information 

Types  Indication 
Submission  Time  Stamp  Indication 
Typed  Body 

User/UA  Capabilities  Registration  (1988) 


mJ 

M 


M 
M 
M 

M 
M 
M 


M-" 

M 

M 

M 

M 

M 


M 
M 
M 
M^ 


Notes : 

1)  In  the  case  of  a  co- located  UA/MTA  or  co- located  UA/MS , 
the  method  and  extent  to  which  this  Element  of  Service 
is  provided  is  a  local  matter;   it  is  not  necessarily 
testable  in  the  absence  of  support  for  the  P3  or  P7 
protocol . 
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Table  8.5.     IPM  Kernel:   IPM  Service  Optional  User  Facilities 


Element  of  Service 

Orig 

Recep 

Alternate  Recipient  Allowed 

0 

- 

Alternate  Recipient  Assignment 

- 

0 

Authorizing  Users  Indication 

0 

M 

Auto -forwarded  Indication 

0 

M 

Blind  Copy  Recipient  Indication 

0 

M 

Body  Part  Encryption  Indication 

0 

M 

Conversion  Prohibition 

M 

M 

Conversion  Prohibition  in  Case  of  Loss  of 

Information  (1988) 

0 

0 

Cross  Referencing  Indication 

0 

M 

Deferred  Deliver}' 

M 

- 

Deferred  Delivery  Cancellation 

0 

- 

Delivery  Notification 

M 

- 

Disclosure  of  Other  Recipients 

0 

M 

DL  Expansion  History  Indication  (1988) 

- 

M 

DL  Expansion  Prohibited  (1988) 

M 

- 

Expiry  Date  Indication 

0 

M 

Explicit  Conversion 

0 

- 

Forwarded  IP-message  Indication 

0 

M 

Grade  of  Delivery  Selection 

M 

M 

Hold  for  Delivery 

- 

0 

Implicit  Conversion 

- 

0 

Importance  Indication 

0 

M 

Incomplete  Copy  Indication  (1988) 

0 

0 

Language  Indication  (1988) 

0 

M 

Latest  Delivery  Designation  (1988) 

0 

- 

Multi-Destination  Delivery 

M 

- 

Multi-part  Body 

0 

M 
M^ 

Non-receipt  Notification  Request 

0 

Obsoleting  Indication 

0 

M 

Originator  Indication 

M 

M 

Originator  Requested  Alternate  Recipient  (88) 

0 

- 

Prevention  of  Non-delivery  Notification 

0 

- 

Primary  and  Copy  Recipients  Indication 

M 

M 

Probe 

0 

- 

Receipt  Notification  Request  Indication 

0 

0 

Redirection  Disallowed  by  Originator  (1988) 

0 

Redirection  of  Incoming  Messages  (1988) 

0 

Reply  Request  Indication 

0 

M 

Replying  IP-message  Indication 

M 

M 

Requested  Delivery  Method  (1988) 

M 

Restricted  Delivery  (1988) 

0 

Return  of  Content 

0 

Sensitivity  Indication 

0 

M 

Subject  Indication 

M 

M 

Use  of  Distribution  List  (1988) 

0 
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Table  8.5.     IPM  Kernel:   IPM  Service  Optional  User  Facilities  (Cont.) 


Notes : 

1)  Support  of  Non-Receipt  Notification  Request  on 

reception  does  not  require  the  capability  to  generate 
a  non-receipt  notification  in  the  case  of  an 
implementation  in  which  a  non- receipt  condition  cannot 
occur . 


8.6.3  Interpersonal  Messaging  Protocol  (P2) 

The  requirements  for  support  of  Interpersonal  Messaging  Protocol 
(P2)  elements  are  detailed  in  section  8.17.2  (Appendix  A). 

8.6.4  Body  Part  Support 

This  section  specifies  the  requirements  for  support  of  IPM  body 
part  types  by  a  UA  conforming  to  this  Agreement. 

The  classification  scheme  for  support  of  IPM  body  part  types  is 
as  defined  in  section  8.5.2. 

The  requirements  for  support  of  IPM  body  part  types  for 
origination  and  reception  are  distinguished.  Body  part  types 
which  are  new  in  the  1988  MHS  standards  are  indicated  as  (1988). 

A  UA  must  support  those  IPM  body  part  types  defined  in  Annex  E  of 
X. 420(1988)  as  listed  and  qualified  in  table  8.6  below.  If  an 
implementation  supports  a  particular  body  part  type  for 
reception,  it  should  also  be  able  to  support  that  body  part  type 
for  reception  if  it  is  part  of  a  forwarded  message. 

Any  basic  body  part  type  that  is  supported  on  reception  must  be 
supported  as  integer  encoding  (ASN.l  context-specific  identifier) 
and  as  object  identifier  (externally-defined)  encoding. 

All  body  parts  with  integer-encoded  identifiers  in  the  range  0  up 
to  and  including  16K-1  are  legal.  Body  part  integer-encoded 
identifiers  corresponding  to  X.121  country  codes  should  be 
interpreted  as  described  in  figure  8.5.  These  privately-defined 
body  part  types  are  specified  as  an  interim  measure  to  provide 
backward  compatibility  with  1984  MHS  implementations.  For 
interworking  between  UAs  based  on  the  1988  (or  later)  MHS 
standards,  it  is  strongly  recommended  that  the  externally-defined 
body  part  be  used  instead. 
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Table  8.6.     IPM  Kernel:  Body  Part  Types 


Body  Part  Type 

Orig 

Recep 

IA5Text 

M 

M 

Voice 

0 

0 

G3Facsimlle 

0 

0 

G4Classl 

(TIFO) 

0 

0 

Teletex 

0 

0 

Videotex 

0 

0 

Encrypted 

0 

0 

Message 

(Forwardedl PMe  s  s  age ) 

0 

M 

MixedMode 

(TIFl) 

0 

0 

Bi lateral lyDefined 

(Unidentified) 

0 

0 

National lyDefined 

0 

0 

External lyDefined 

(1988) 

0 

0/M^ 

Private lyDefined 

(see  figure  8.5) 

0 

0 

GeneralText 

(1988  -  extended) 

* 

* 

Notes : 

1)  Any  basic  body  part  type  that  is  supported  on 

reception  as  integer  encoding  must  also  be  supported 
as  object  identifier  encoding.  Support  for  all  other 
externally  defined  body  parts  is  optional. 
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BodyPart  :  :=    CHOICE  { 

ia5-text  [0]  IA5TextBodyPart , 

externally-defined  [15]  External lyDef inedBodyPart , 

[234]  UKBodyParts, 

[310]  USABodyParts , 
} 

Where  UKBodyParts  and  USABodyParts  (privately  defined)  are 
defined  as: 

SEQUENCE  {BodyPartNumber ,  ANY) 
BodyPartNumber  : :=  INTEGER 

These  privately-defined  body  part  types  are  specified  as  an 
interim  measure  to  provide  backward  compatibility  with  1984 
MHS  implementations.     For  interworking  between  UAs  based  on 
the  1988  (or  later)  MHS  standards,  it  is  strongly 
recommended  that  the  externally-defined  body  part  be  used 
instead. 

The  undefined  bit  in  PI  EncodedlnformationTypes  must  be  set 
when  a  message  contains  a  privately  defined  body  part.  Each 
UA  that  expects  such  body  parts  should  include  undefined  in 
the  set  of  deliverable  EncodedlnformationTypes  it  registers 
with  the  MTA. 

Body  part  numbers  are  interpreted  relative  to  the  body  part 
type  in  which  they  are  used.     NIST  registers  body  part 
niambers  for  privately-defined  formats  within  the  United 
States . 


Figure  8.5.     Privately-Defined  Body  Parts. 


8.7    MESSAGE  STORE 


8.7.1  Introduction 

This  section  specifies  Agreements  for  implementation  of  the 
Message  Store  (MS)  Functional  Group.  The  MS  is  responsible  for 
accepting  delivery  of  messages  on  behalf  of  a  single  end-user, 
and  retaining  the  messages  until  the  end-user's  UA  is  able  to 
retrieve  them.  Message  submission  and  some  administration 
services  are  provided  via  "pass- through"  to  the  MTS .  Figure  8.6 
illustrates  the  logical  relationship  of  the  MS  to  the  UA  and  MTS. 
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Figure  8.6.     Message  Store  Model 


The  Agreements  in  this  section  specify  the  Message  Store's  use  of 
the  retrieval,  delivery,  and  administration  services.  Agreements 
on  submission  services  are  specified  in  section  8.8,  which 
describes  support  for  the  remote  UA. 

The  goal  of  the  Agreements  in  this  section  is  to  define  the 
minimal  set  of  features  which  are  necessary  to  provide  useful 
Message  Store  services,  independent  of  the  MTA  implementation 
version  (i.e.,   1984  or  1988). 


8.7.2  Scope 

The  scope  of  the  Agreements  in  this  section  is  depicted  in  figure 
8.7  below,  and  is  confined  to  the  services  and  protocols  between 
the  boundaries  shown  (marked  with  asterisks) .  Requirements  for 
the  UA  and  MTA  are  addressed  only  to  the  extent  that  they  affect 
the  Message  Store  and  remote  User  Agent  services  and  protocols. 
This  reflects  the  additional  services  required  at  the  UA  to 
support  MS  access  and  at  the  MTA  to  support  a  remote  MS. 


* 

1 

P7 

P3 

* 
1 

UA 

MS 

MTA 

I 


Figure  8.7.     Scope  of  Message  Store  Agreements. 

The  UA,  MS  and  MTA  configuration  is  not  restricted;  any  of  these 
components  may  be  co- located,  although  they  are  depicted  as 
logically  separate.  In  the  case  of  a  co- located  UA  and  MS,  a 
proprietary  interface  may  be  used  instead  of  P7 .     In  the  case  of 
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a  CO- located  MS  and  MTA,  a  proprietary  interface  may  be  used 
instead  of  P3 . 


8.7.3        Elements  of  Service 

This  section  specifies  the  requirements  for  support  of  Elements 
of  Service  to  provide  a  Message  Store  conforming  to  the  Message 
Store  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is 
as  defined  in  section  8.5.2. 

Support  for  Elements  of  Service  is  specified  both  for  the  Message 
Store  itself  and  for  the  User  Agent. 


Table  8.7.     Message  Store:  Elements  of  Service 


Element  of  Service 

UA 

MS 

Stored  Message  Deletion 

M 

M 

Stored  Message  Fetching 

M 

M 

Stored  Message  Listing 

M 

M 

Stored  Message  Summary 

M 

M 

Stored  Message  Alert 

0 

0 

Stored  Message  Auto  Forward 

0 

0 

8.7.4        Attribute  Types 

Requirements  for  support  of  the  attributes  used  in  the  Message 
Store  are  detailed  in  sections  8.17.5  and  8.17.6  (Appendix  A), 
section  8.17.5  specifies  support  for  the  General  Attributes  of 
the  Message  Store,  while  section  8.17.6  specifies  support  for  the 
IPM  Message  Store  Attributes. 

There  are  two  classes  of  support  for  General  Attributes  in  the 
Message  Store:  Basic  and  IPM. 

The  Basic  MS  is  intended  to  support  the  use  of  the  MS  as  a 
continuously  available,  reliable  device  (such  as  a  spooling 
entity)  for  receiving,  storing,  and  forwarding  messages  and 
reports.  The  Basic  MS  is  not  required  to  support  any  IPM 
attributes . 

The  IPM  MS  provides  more  flexible  access  to  the  General 
Attributes  as  well  as  supporting  IPM  Attributes. 
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IPM  User  Agents  can  make  use  of  either  the  Basic  or  IPM  MS. 
section  8.17.6   is  to  be  read  in  accordance  with  Annex  C  of  X.420 
(1988)  . 

8.7.5  Pragmatic  Constraints  for  Attribute  Types 

There  are  no  additional  pragmatic  constraints  for  attribute  types 
beyond  those  of  the  basic  standards. 

8.7.6  Implementation  of  the  MS  with  1984  Systems 

While  the  Message  Store  is  part  of  the  1988  MHS  standards, 
implementation  of  MS  services  with  a  1984  MTA  is  possible.  In 
order  to  interoperate  with  other  1984  MHS  systems, 
implementations  with  this  configuration  should  adhere  to  the 
following  guidelines: 

o        The  UA  must  generate  1984  P2  PDUs  ; 

o  The  UA  must  identify  the  content  protocol  as  integer  2  to 
the  MS; 

o  The  MS  must  be  co- located  with  the  MTA  unless  1988  P3 
support  is  provided  on  the  1984  MTA  as  well. 

To  meet  these  guidelines,   the  UA  may  be  implemented  as  follows: 

o  The  UA  could  conform  to  X. 420(1984),  with  1988  UA  extensions 
for  utilizing  the  MS  services; 

o  The  UA  could  be  a  1988  UA  with  restrictions  on  protocol 
elements  generated  and  by  identifying  the  content  type  as 
integer  2  rather  than  22.  No  1988-specif ic  elements  should 
be  generated. 

Details  of  the  interface  between  the  1988  MS  and  the  1984  MTA 
when  CO- located  are  beyond  the  scope  of  these  Agreements. 

8.7.7  MS  Access  Protocol  (P7) 

The  requirements  for  support  of  MS  Access  Protocol  (P7)  elements 
by  an  MS  and  a  remote  MS-user  are  detailed  in  section  8.17.4 
(Appendix  A) . 

The  requirements  for  support  of  MS  Access  Protocol  (P7) 
application  contexts  by  an  MS  and  an  MS-user  are  as  specified  in 
clauses    6.1    and    10.1    of    X. 419(1988)     (ISO    10021-6)    with  the 
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additional  requirement  that  an  MS-user  must  at  least  support  the 
ms-access  application  context,  as  defined  in  table  8.8. 


Table  8.8.     Application  Contexts  Support  for  P7 


Application  Context 

MS 

MS-user 

ms-access 

ms- re liable -access 

Mandatory 
Optional 

Mandatory 
Optional 

Use  of  the  underlying  services  to  support  these  application 
contexts  is  specified  in  section  8.14. 

8.7.8        MTS  Access  Protocol  (?3) 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  elements 
by  an  MTA  and  an  MS  where  the  MS  is  not  co- located  with  the  MTA 
are  detailed  in  section  8.17.3  (Appendix  A). 

The  requirements  for  support  of  MTS  Access  Protocol  (P3) 
application  contexts  by  an  MTA  and  an  MS  in  such  a  scenario  are 
as  specified  in  clauses  6.1  and  10.1  of  X. 419(1988)  (ISO  10021-6) 
with  the  additional  requirement  that  a  remote  MS  must  at  least 
support  the  mts-access  and  mts-forced-access  application 
contexts,  as  defined  in  table  8.9. 


Table  8.9.     Application  Contexts  Support  for  P3 


Application  Context 

MTA 

MS 

mts-access 

mts-forced-access 

mts- re liable -access 

mts- forced- re liable -access 

Mandatory 
Mandatory 
Optional 
Optional 

Mandatory 
Mandatory 
Optional 
Optional 

Use  of  the  underlying  services  to  support  these  application 
contexts  is  specified  in  section  8.14. 

REMOTE  USER  AGENT  SUPPORT 
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8.8.1  Introduction 

This  section  specifies  Agreements  for  implementation  of  the 
Remote  User  Agent  Functional  Group,  i.e.,  for  support  of  an  IPM 
UA  that  is  not  co-located  with  its  MTA.  Support  of  other  classes 
of  UA  is  for  further  study. 

The  goal  of  the  Agreements  in  this  section  is  to  define  the 
minimal  set  of  features  which  are  necessary  to  provide  useful 
remote  User  Agent  services,  independent  of  the  MTA  implementation 
version  (i.e.,   1984  or  1988). 

8.8.2  Scope 

The  scope  of  the  Agreements  in  this  section  is  depicted  in  figure 
8.8,  and  is  confined  to  the  services  and  protocols  between  the 
boundaries  shown  (marked  with  asterisks) .  Requirements  for  the 
UA  and  MTA  are  addressed  only  to  the  extent  that  they  affect  the 
remote  User  Agent  services  and  protocols.  Access  to  a  Message 
Store  by  a  remote  User  Agent  is  covered  in  section  8.7. 


1 

P3 

* 
1 

UA 

MTA 

I 


Figure  8.8.     Scope  of  Remote  User  Agent  Agreements. 
8.8.3        Elements  of  Service 

This  section  specifies  the  requirements  for  support  of  Elements 
of  Service  for  conformance  to  the  Remote  User  Agent  Functional 
Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is 
as  defined  in  section  8.5.2. 

Support  for  Elements  of  Service  is  specified  both  for  the  MT 
Service  and  for  the  IPM  Service,  and  is  in  addition  to  the 
support  requirements  specified  in  sections  8.5  and  8.6  if  this 
Functional  Group  is  supported. 
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Table  8.10.     Remote  User  Agent  Support:  MT  Elements  of  Service 


Element  of  Service 

Origination 

Reception 

Access  Management 

M 

M 

Hold  for  Delivery 

M 

User/UA  Capabilities  Registration 

M 

Table  8.11.     Remote  User  Agent  Support:   IPM  Elements  of  Service 

Element  of  Service 

Origination 

Reception 

Access  Management 

M 

M 

Hold  for  Delivery 

M 

User/UA  Capabilities  Registration 

M 

8.8.4        MTS  Access  Protocol  (P3) 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  elements 
by  an  MTA  and  an  MTS -user  (whether  UA  or  UA/MS)  where  the  MTS- 
user  is  not  co- located  with  the  MTA  are  detailed  in  section 
8.17.3  (Appendix  A). 

The  requirements  for  support  of  MTS  Access  Protocol  (P3) 
application  contexts  by  an  MTA  and  an  MTS -user  in  such  a  scenario 
are  as  specified  in  clauses  6.1  and  10.1  of  X. 419(1988)  (ISO 
10021-6)  with  the  additional  requirement  that  a  remote  MTS-user 
must  at  least  support  the  mts-access  and  mts-forced-access 
application  contexts,  as  defined  in  table  8.12. 


Table  8.12.     Application  Contexts  Support  for  P3 


Application  Context 

MTA 

MTS-user 

mts-access 
mts-forced-access 
mts- re liable -access 
mts-forced- re liable -access 

Mandatory 
Mandatory 
Optional 
Optional 

Mandatory 
Mandatory 
Optional 
Optional 

Use  of  the  underlying  services  to  support  these  application 
contexts  is  specified  in  section  8.14. 
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8.9  NAMING.  ADDRESSING  &  ROUTING 
See  Working  Document. 

8.10  MHS  MANAGEMENT 
For  further  study. 

8.11  MHS  SECURITY 
See  Working  Dociament. 

8. 12  SPECIALIZED  ACCESS 
See  Working  Document. 

8.13  CONVERSION 

See  Working  Document. 

8.14  USE  OF  UNDERLYING  LAYERS 


8. 14. 1  MTS  Transfer  Protocol  (PI) 

The  PI  protocol  is  mapped  onto  the  Reliable  Transfer  Service 
Element  (RTSE)  either  in  X. 410- 1984  mode  or  in  normal  mode,  as 
specified  in  section  8.5.3.  In  X. 410-1984  mode,  the  RTSE  makes 
direct  use  of  the  services  provided  by  the  Session  Layer,  as 
specified  in  chapter  5  (Upper  Layers)  of  the  Stable 
Implementation  Agreements.  In  normal  mode,  the  RTSE  makes  use  of 
the  services  provided  by  the  Association  Control  Service  Element 
(ACSE)  and  Presentation  Layer,  as  defined  in  chapter  5  (Upper 
Layers)  of  these  Agreements. 

8.14.2  MTS  Access  Protocol  (P3)  and  MS  Access  Protocol  (P7) 

The  P3  and  P7  protocols  make  use  of  the  services  provided  by  the 
Remote  Operations  Service  Element  (ROSE) ,  Association  Control 
Service  Element  (ACSE),  Presentation  Layer,  and,  optionally,  the 
Reliable  Transfer  Service  Element  (RTSE) ,  as  defined  in  chapter  5 
(Upper  Layers)  of  these  Agreements.  It  is  recommended  that  RTSE 
be  used  for  recovery  purposes  when  the  implementation  uses  a 
Transport  Class  other  than  4. 
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8.15  ERROR  HANDTJNP, 

Editor's  Note:  The  material  in  8.15  was  not  explicitly  included 
in  a  proposal  brought  to  the  OIW  Plenary  in 
December  1989. 

This  section  describes  appropriate  actions  to  be  taken  upon  receipt  of 
protocol  elements  which  are  not  supported  in  this  profile:  malformed 
PDUs ,  unrecognized  0/R  Name  forms,  content  errors,  errors  in  reports, 
and  unexpected  values  for  protocol  elements. 

An  implementation  must  be  able  to  report  all  error  conditions  which 
may  occur  with  the  appropriate  error  information  as  defined  in  the 
referenced  base  standards.     An  implementation  must  be  able  to  handle 
receipt  of  all  error  indications  which  are  defined  in  the  referenced 
base  standards.     An  implementation  must  also  be  tolerant  of  any 
additional  error  indications  which  are  not  currently  defined,  but  is 
not  required  to  be  able  to  interpret  such  error  information. 

8.16  CONFORMANCE 

For  this  section,  the  term  conformance  is  as  defined  in  ISO  9646. 

Bilateral  agreements  between  domains  may  be  implemented  in  addition  to 
the  requirements  stated  in  this  document.     Conformance  to  this 
Agreement  requires  the  ability  to  exchange  messages  without  use  of 
bilateral  agreements. 

In  order  to  achieve  a  more  precise  definition  of  conformance 
requirements  according  to  the  functionality  supported  by  an 
implementation,  the  concept  of  Functional  Groups  has  been  introduced. 
A  Functional  Group  is  a  set  of  related  Elements  of  Service  and 
associated  protocol  elements  which  provide  a  discrete  area  of 
functionality. 

Conformance  to  this  Agreement  requires  as  a  minimum  that  all  Mandatory 
Elements  of  Service  listed  in  this  chapter  are  supported  in  the  manner 
defined  in  the  MHS  standards,  as  qualified  in  this  Agreement,  for  each 
of  the  Functional  Groups  claimed.     Any  Optional  Elements  of  Service 
for  which  support  is  claimed  must  also  be  supported  as  defined  in  the 
MHS  standards  and  as  qualified  in  this  Agreement.  Pragmatic 
constraints  shall  be  observed  as  specified  in  the  CCITT  X.400  (1988) 
Series  of  Recommendations.     It  is  not  necessary  to  implement  the 
recommended  practices  of  Appendix  C  in  order  to  claim  conformance  to 
this  Agreement. 

Conformance  requirements  for  support  of  Functional  Groups  by 
particular  configuration  types  (see  sec.  8.2)  are  listed  below.  An 
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implementation  may  claim  conformance  to  multiple  configuration  types 
(e.g.,   "MTA+UA"  and  "Class  B  MTA  only"). 


Table  8.23.     Conformance  Requirements 


Configuration^ 

MT 
Kernel 

IPM 
Kernel 

Functional  Groups 
MS'^  Remote  DL 
UA 

Directory 

MTA  +  UA^ 

m2 

M 

0  0 

0 

MTA  +  MS 

M 

MOO 

0 

MTA  only^ 

:  class 

A 

M 

0 

0 

class 

B 

M 

M  0 

0 

class 

C 

M 

0 

0 

MS  +  UA 

M 

M 

0 

MS  only 

M 

* 

UA  only: 

P7 

M 

M 

0 

P3 

M 

M 

0 

Notes : 

1)  There  are  three  conformance  levels  defined  for  the  MT  Kernel  in 
this  Agreement: 

o  A  class  'A'  MT  Kernel  implementation  conveys  a  message,  probe,  or 
report  to  another  MT  Kernel  using  standard  means.  A  class  'A'  MT 
Kernel  is  specifically  implemented  in  order  to  transfer  messages, 
probes,  and  reports  which  have  previously  been  transferred  and 
need  not  support  submission  and  delivery.  A  class  'A'  MT  Kernel 
may  perform  other  activities  such  as  originate  reports,  expand 
distribution  lists,  and  perform  conversions. 

o  A  class  'B'  MT  Kernel  implementation  supports  submission, 
delivery,  and  transfer  using  standard  means,  i.e.,  P3  and  PI.  A 
class  'B'  MT  Kernel  need  not  support  the  transfer  of  previously 
transferred  messages,  probes,  or  reports. 

o  A  class  'C  MT  Kernel  implementation  requires  support  for 
transfer  of  messages,  probes,  and  reports  to  another  MT  Kernel 
using  standard  means.  A  class  'C  MT  Kernel  does  not  require 
support  for  the  transfer  of  previously  transferred  messages, 
probes,  and  reports,  and  message  submission  and  delivery  is 
achieved  by  non-standard  means. 
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An  MTA  may  conform  to  one  or  more  of  the  MT  Kernel  classes.  For 
example,  a  class  'B'  or  'C  MT  Kernel  which  supports  the  transfer  of 
previously  transferred  messages,  probes,  and  reports  is  also 
conformant  to  a  class  'A'  MT  Kernel.  Figure  8.10  illustrates  several 
combinations  of  MT  Kernel  conformance  classes.  Additional 
combinations  are  possible. 


UA 


MS 


MTA 

Class  B 


MTA 

Class  A 


MTA 

Class  AB 


Standard 
Non-standard 


MTA 
Class  C 


UA 


MS 


UA 


MS 


Figure  8.10.     MT  Kernel  Conformance  Classes 


2)  Optional  elements  of  the  IPM  Kernel  need  not  be  supported  in  the 
MT  Kernel  in  this  configuration,  for  example  Probe  and  Deferred 
Delivery  Cancellation. 

3)  The  designation  of  a  '  +  '  in  a  configuration  (e.g.,  'MTA+MS') 
implies  that  there  is  no  exposed  protocol  in  the  interface 
between  the  two  components . 

4)  There  are  two  conformance  levels  defined  for  MS  support: 

o  A  Basic  MS  only  requires  support  for  the  General  Attributes  as 
specified  in  section  8.17.5 

o  An  IPM  MS  requires  support  from  both  the  General  Attributes  and 
IPM  Attributes  as  specified  in  sections  8.17.5  and  8.17.6, 
respectively. 


8.17  APPENDIX  A:     MHS  PROTOCOL  SPECIFICATIONS 


The  following  tables  (8.25-8.30)  specify  the  requirements  for  support 
of  MHS  protocol  elements  for  conformance  to  this  Agreement.     It  should 
be  noted  that  the  tables  specify  minimum  support  for  conformance  to 
the  relevant  Kernel  functional  groups  and  where  appropriate  also 
specify  enhanced  support  requirements  where  one  or  more  further 
functional  groups  are  claimed.     All  element  support  is  subject  to 
further  review  and  may  be  upgraded  in  later  versions  of  this 
Agreement . 
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The  protocol  support  classification  scheme  used  in  this  version  of 
this  Agreement  is  described  below.     However,   it  should  be  noted  that 
the  scheme  is  currently  under  review  both  within  the  NIST  X.400  SIG 
and  in  the  EWOS/ETSI  MHS  groups  and  is  likely  to  be  revised  for  later 
versions  of  this  Agreement. 

The  classification  of  support  for  a  protocol  element  specifies  the 
requirements  for  implementations  conforming  to  this  Agreement  to  be 
able  to  generate,   receive  and  process  that  protocol  element,  as 
appropriate  (the   'receiving'   role  includes  relaying  where 
appropriate) .     The  classification  of  support  for  each  protocol  element 
is  relative  to  that  for  its  containing  element.     Where  subelements 
within  a  containing  element  are  not  listed,   then  their  support 
classification  shall  be  assumed  to  be  that  of  the  containing  element. 
Where  the  range  of  values  to  be  supported  for  an  element  is  not 
specified,   then  all  values  defined  in  the  base  standard  shall  be 
supported. 

The  classifications  have  been  revised.  The  new  classifications  relate 
to  the  classifications  in  the  1988  Stable  Agreements  as  shown  in  table 
8.24. 


Table  8.24.     Classification  Changes 


Former 
Category 

New 

Originator 
Category 

Recipient 
Category 

Generatable  (G) 
Supported  (H) 
Mandatory  (M) 
Required  (R) 
Unsupported  (X) 

Mandatory  (M) 
Optional  (0) 
Mandatory  (M) 
Mandatory  (M) 
Optional  (0) 

Mandatory  (M) 
Mandatory  (M) 
Mandatory  (M) 
Mandatory  (M) 
Optional  (0) 

The  support  classifications  are  stated  for  both  Origination  and 
Reception  (0/R)  in  the  following  tables  (8.25-8.30).  The  defined 
support  for  each  is  stated  within  each  classification. 

Mandatory  (M) 

Origination:   Implementations  conforming  to  this  Agreement  shall 
generate  this  element  in  all  information  objects  in  which,  according 
to  the  base  standards,   it  shall  occur. 

Reception:   Implementations  conforming  to  this  Agreement  shall  process 
this  element  appropriately,  and  shall  regard  its  absence  as  a  protocol 
violation  unless  otherwise  specified  in  the  base  standards.  When  an  MS 
or  MTA  receives  a  protocol  element  that  according  to  the  base  standard 
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and  this  profile  should  be  conveyed  to  another  MHS  entity  (MTA,  MS,  or 
UA) ,   the  MS  or  MTA  is  required  to  preserve  the  semantics  of  that 
protocol  element  in  the  message  conveyed. 

Optional  (0) 

Origination:   Implementations  conforming  to  this  Agreement  may 
optionally  be  capable  of  generating  this  protocol  element,  but  are  not 
required  to  do  so. 

Reception:   Implementations  conforming  to  this  Agreement  may,  but  are 
not  required  to  be  capable  of  processing  this  protocol  element  other 
than  to  observe  any  criticality  indication.  When  an  MS  or  MTA  receives 
a  protocol  element  that  according  to  the  base  standard  and  this 
profile  should  be  conveyed  to  another  MHS  entity  (MTA,  MS,   or  UA) ,  the 
MS  or  MTA  is  required  to  preserve  the  semantics  of  that  protocol 
element  in  the  message  conveyed.   The  absence  of  this  element  should 
not  be  assumed  to  convey  any  significance. 

Note:         Some  protocol  elements  may  not  be  conveyed,  if 
downgrading  rules  are  applied. 

To  Be  Determined  (*)   -  the  support  classification  for  this  protocol 
element  has  yet  to  be  determined. 
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8.17.1      MTS  Transfer  Protocol  (PI) 


Table  8.25.     Classification  of  the  PI  Protocol  Elements 


MTS  Transfer  Protocol  (Pi) 

Part     1  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

Operations 

MTABind 

M 

M/M 

M/M 

MTABind 

MTAUnbind 

M 

M/M 

M/M 

MTSE 

See  protocol  elements 

MessageTransf er 

M 

M/M 

M/M 

ProbeTransfer 

M 

M/M 

M/M 

ReportTransfer 

M 

M/M 

M/M 

Arguments/Results 

MTABind 

ARGUMENT 

<NULL> 

0 

0/M 

0/M 

See  Note  2 

<SET> 

0 

M/M 

M/M 

initiator -name 

M 

M/M 

M/M 

initiator -credentials 

M 

M/M 

M/M 

simple 

0 

M/M 

M/M 

strong 

0 

0/0 

0/0 

security- context 

0 

0/0 

0/0 

RESULT 

<NULL> 

0 

0/M 

0/M 

See  Note  2 

<SET> 

0 

M/M 

M/M 

responder-name 

M 

M/M 

M/M 

re sponder- credentials 

M 

M/M 

M/M 

simple 

0 

M/M 

M/M 

strong 

0 

0/0 

0/0 

Notes : 

1)       The  MT  Kernel  implementation  classes  are  defined 

in  sec. 

8. 16. 

2)       The  action  to  be  taken  on  receipt 

of  null  MTABind 

authentication  is  that  an  implementation  must  understand  the 

semantics,  but  the  form  of  authentication  that  is  acceptable 

is  a  local  matter. 
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MTS  Transfer  Protocol  (Pi) 

Part    2  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

MTS-APDU 

message 

M 

M/M 

0/M 

envelope 

M 

M/M 

M/M 

MessageTransferEnvelope 

content 

M 

M/M 

M/M 

See  P2  -  else  undefined 

probe 

M 

M/M 

0/M 

ProbeTransferEnvelope 

report 

M 

M/M 

M/M 

envelope 

M 

M/M 

M/M 

ReportTransferEnvelope 

content 

M 

M/M 

M/M 

ReportTransferContent 

Me ssageTransfer Envelope 

message- identifier 

M 

M/M 

M/M 

MTSIdentifier 

originator -name 

M 

M/M 

M/M 

ORName 

original -encoded- information- 

types 

0 

M/M 

0/0 

Enc  o  de  dinf o  rma t  i  onTyp  e  s 

content- type 

M 

M/M 

M/M 

built-in 

0 

M/M 

0/0 

external 

0 

0/M 

0/0 

content- identifier 

0 

0/M 

0/0 

priority 

0 

M/M 

0/M 

All  values 

per-message- indicators 

0 

M/M 

0/M 

disclosure -of- recipients 

0 

0/M 

0/M 

implicit -conversion-prohibited 

0 

M/M 

0/M 

alternate -recipient -allowed 

0 

M/M 

0/0 

content- re turn- request 

0 

0/0 

0/0 

deferred-delivery- time 

0 

0/0 

0/0 

per- domain-bilateral - 

information 

0 

0/0 

0/0 

PerDomainBilaterallnfo 

trace -  information 

M 

M/M 

M/M 

Tracelnformation 

extensions 

0 

M/M 

M/M 

ExtensionField 

recipient- reassignment- 

prohibited 

0 

M/M 

M/M 

dl- expansion- prohibited 

0 

M/M 

0/M 

convers ion- with- loss - 

prohibited 

KJ 

U/W 

r>  /M 
u/n 

latest -de livery- time 

0 

0/0 

0/0 

See  X.411,  14.1.1  note  2 

originator -re turn- address 

0 

0/0 

0/0 

originator- certificate 

0 

0/0 

0/0 

content -confidentiality- 

algorithm-  identifier 

0 

0/0 

0/0 

message-origin- 

authent icat ion- check 

0 

0/0 

0/0 

message -security- label 

0 

0/0 

0/0 

content- correlator 

0 

0/0 

0/0 
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MTS  Transfer  Protocol  (PI) 

Part    3  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments /References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

dl - expans  ion-his  tory 

0 

0/M 

0/M 

DLExpansionHistory 

internal - trace -  information 

0 

M/M 

M/M 

InternalTracelnfo 

per -recipient -fie Ids 

M 

M/M 

M/M 

recipient -name 

M 

M/M 

M/M 

ORName 

original ly- specif ied- 

recip lent -number 

M 

M/M 

M/M 

per-recipient- indicators 

M 

M/M 

M/M 

explicit- conversion 

0 

0/0 

0/0 

extensions 

0 

0/M 

0/M 

ExtensionField 

originator-requested- 

alternate- recipient 

0 

0/0 

0/0 

requested-del i ve  ry - me  tho d 

0 

M/M 

0/M 

phy s  ical - f orwarding- 

prohibited 

0 

0/0 

0/0 

physical -forwarding- address - 

request 

0 

0/0 

0/0 

physical -de livery -modes 

0 

0/0 

0/0 

registered-mail- type 

0 

0/0 

0/0 

recipient -number -for -advice 

0 

0/0 

0/0 

physical -rendition- attributes 

0 

0/0 

0/0 

physical-delivery-report- 

request 

0 

0/0 

0/0 

message- token 

0 

0/0 

0/0 

content- integrity-check 

0 

0/0 

0/0 

proof -of -de livery- request 

0 

0/0 

0/0 

redirection-history 

0 

0/M 

0/M 

ProbeTransferEnvelope 

probe -identifier 

M 

M/M 

M/M 

MTSIdentifier 

originator -name 

M 

M/M 

M/M 

ORName 

original-encoded- information- 

types 

0 

M/M 

0/0 

EncodedlnformationTypes 

J  r 

content- type 

M 

M/M 

M/M 

built-in 

0 

M/M 

0/0 

external 

0 

0/M 

0/0 

content- Identifier 

0 

0/M 

0/0 

content - length 

0 

M/M 

0/0 

per-message- indicators 

0 

M/M 

0/M 

disclosure -of -recipients 

0 

0/0 

0/0 

implicit -conversion- prohibited 

0 

M/M 

0/M 

alternate -recipient -allowed 

0 

M/M 

0/0 

content- re turn- request 

0 

0/0 

0/0 
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MTS  Transfer  Protocol  (PI) 

Part    4  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

s 

0/R 

0/R 

See  Note  1 

pe r-domain-bi lateral - 

information 

0 

0/0 

0/0 

PerDomainBi later allnfo 

trace -  information 

M 

M/M 

M/M 

Tracelnformation 

0 

M/M 

M/M 

Extens  ionFie Id 

rec  ipient - reass  ignment- 

prohibited 

0 

0/0 

0/0 

C  A.  L' d  L  IS  X  W  1.1         1.  \J  L  L  d.U  J-  \^^\X 

0 

M/M 

0  /M 

conversion -with- loss  - 

prohibited 

0 

0/0 

0/0 

originator -certificate 

0 

0/0 

0/0 

message - security- labe 1 

0 

0/0 

0/0 

content -correlator 

0 

0/0 

0/0 

■nrobe-ori  pin-authentication- 

check 

0 

0/0 

0/0 

dl- expans  ion -hi story 

0 

0/M 

0/M 

DLExp  ansionHistory 

internal -  trace -  information 

0 

M/M 

M/M 

InternalTracelnfo 

per -rec ipient- fields 

M 

M/M 

M/M 

rec ipient -name 

M 

M/M 

M/M 

ORName 

originally-specif ied- 

rec ipient -number 

M 

M/M 

M/M 

per-recipient- indicators 

M 

M/M 

M/M 

explicit -conversion 

0 

0/0 

0/0 

ext ens  ions 

0 

0/M 

0/M 

Extens  ionFie Id 

or igina tor -request ed- 

alternate- rec ipient 

0 

0/0 

0/0 

r  e  que  sted-del i ve  ry - me  tho  d 

0 

M/M 

0/M 

physical -rendition- at tributes 

0 

0/0 

0/0 

ypdi  Tec t ion -hi St orv 

0 

0/M 

0/M 

ReportTransferEnvelope 

report- identifier 

M 

M/M 

M/M 

MTSIdentif ier 

report -destination- name 

w 

n 

M/M 

M/rl 

ORName 

trace -  information 

M 

M/M 

M/M 

Tracelnformation 

extensions 

0 

M/M 

M/M 

Extens  ionFie Id 

message -security- label 

0 

0/0 

0/0 

or iginator-and-DL- expans ion- 

Or igina torAndDL 

history 

0 

M/M 

0/0 

Expans ionHistory 

report ing-DL-name 

0 

0/0 

0/0 

reporting-MTA- certificate 

0 

0/0 

0/0 

report -origin- authentication- 

check 

0 

0/0 

0/0 

internal - trace -  information 

0 

M/M 

M/M 

InternalTracelnfo 
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MTS  Transfer  Protocoi  (PI) 

Part    5  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

ReportTransf erContent 

subj  ect- identifier 

M 

M/M 

M/M 

MTSIdentifier 

subj  ect- intermediate -  trace - 

information 

0 

M/M 

M/M 

Traceinf ormation 

original-encoded- information- 

types 

0 

M/M 

M/M 

EncodedlnformationTypes 

content- type 

0 

M/M 

M/M 

built-in 

0 

M/M 

M/M 

external 

0 

M/M 

M/M 

content- identifier 

0 

M/M 

M/M 

returned- content 

0 

0/M 

0/0 

additional- information 

0 

0/0 

0/0 

extensions 

0 

0/M 

0/M 

ExtensionField 

content -correlator 

0 

0/M 

0/M 

per -recipient -fie Ids 

M 

M/M 

M/M 

actual -recipient -name 

M 

M/M 

M/M 

ORName 

original ly- spec if ied- 

recip lent -number 

M 

M/M 

M/M 

per-recipient- indicators 

M 

M/M 

M/M 

last- trace- information 

M 

M/M 

M/M 

arrival- time 

M 

M/M 

M/M 

converted- encoded- 

inf ormation- types 

0 

M/M 

M/M 

EncodedlnformationTypes 

report 

M 

M/M 

M/M 

delivery 

0 

M/M 

0/0 

message -de livery- time 

0 

M/M 

M/M 

type-of-MTS-user 

0 

M/M 

0/0 

All  values  =0/M 

non- delivery 

0 

M/M 

M/M 

non- delivery- reason- code 

0 

M/M 

M/M 

non-delivery-diagnostic- 

code 

r\ 

u 

U/n. 

U/M 

originally- intended-recipient- 

name 

0 

M/M 

M/M 

ORName 

supplementary- information 

0 

0/0 

0/0 

extensions 

0 

M/M 

M/M 

Extens  ionFie Id 

redirection-history 

0 

M/M 

M/M 

Redirect ionHistory 

phys  ical -  forwarding- address 

0 

0/0 

0/0 

recipient -certificate 

0 

0/0 

0/0 

proof -of -delivery 

0 

0/0 

0/0 
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MTS  Transfer  Protocol  (PI) 

Part    6  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

Conunon  Data  Types 

Enc  o  de  dl nf o  rma  t  i  onTyp  e  s 

built-in-encoded- information- 

types 

M 

M/M 

M/M 

See  Note  3 

non-basic -parameters 

0 

0/0 

0/0 

external-encoded- information- 

types 

0 

0/M 

0/M 

MTSIdentifier 

global-domain- identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

local- identifier 

M 

M/M 

h/M 

PerDomainBilaterallnfo 

country -name 

M 

M/M 

M/M 

administration- domain-name 

0 

M/M 

M/M 

DomainName 

private-domain- identifier 

0 

M/M 

M/M 

DomainName 

(only  encoded  as  SEQ  if 

both  present) 

bilateral- information 

M 

M/M 

M/M 

Tracelnformation 

TracelnformationElement 

M 

M/M 

M/M 

global-domain- identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

domain-supplied- information 

M 

M/M 

M/M 

arrival- time 

M 

M/M 

M/M 

routing- action 

M 

M/M 

M/M 

relayed 

0 

M/M 

M/M 

rerouted 

0 

0/M 

0/M 

attempted- domain 

0 

0/M 

0/M 

GlobalDomainldentif ier 

deferred- time 

0 

M/M 

M/M 

converted- encoded- 

inf ormation- types 

0 

0/M 

0/M 

EncodedlnformationTypes 

i~'\r\ air  —  Si    i~  '1  f\T\c 

n  /M 

n  /M 

redirected 

0 

0/M 

0/M 

dl-operation 

0 

0/M 

0/M 

ExtensionField 

type 

M 

M/M 

M/M 

criticality 

0 

0/M 

0/M 

for -submission 

0 

0/0 

0/0 

for- transfer 

0 

M/M 

M/M 

for -de livery 

0 

M/M 

M/M 
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MTS  Transfer  Protocol  (PI) 

Part    7  of  9 

MT  Kernel  Support  by  MTS  Class 

Conunents  /References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

value 

M 

M/M 

M/M 

DLExpansionHistory 

DLExpansion 

M 

M/M 

M/M 

ORAddr e  s  s AndOp  1 1 ona ID i r e c  t o ry 

Name 

M 

M/M 

M/M 

ORName 

dl - expans  ion- time 

M 

M/M 

M/M 

InternalTracelnformation 

InternalTracelnf ormationElement 

M 

M/M 

M/M 

global-domain- identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

mta-name 

M 

M/M 

M/M 

mta- supplied- information 

M 

M/M 

M/M 

arrival- time 

M 

M/M 

M/M 

routing- act ion 

M 

M/M 

M/M 

relayed 

0 

M/M 

M/M 

rerouted 

0 

0/M 

0/M 

attempted 

0 

mta 

r\ 
0 

U/M 

U/M 

domain 

0 

0/M 

0/M 

GlobalDomainldentif ier 

deferred- time 

0 

0/M 

0/M 

other -act ions 

0 

0/M 

0/M 

redirected 

0 

0/M 

0/M 

dl-operation 

0 

0/M 

0/M 

Or igina torAndDLExpans  ionHis  tory 

originator- or- dl -name 

M 

M/M 

M/M 

origination-or-expansion- time 

M 

M/M 

M/M 

Redirect ionHis tory 

Redirection 

M 

M/M 

M/M 

intended- rec  ip lent -name 

M 

M/M 

M/M 

ORAddressAndOptionalDirectory 

Name 

M 

M/M 

M/M 

ORName 

redirection- time 

M 

M/M 

M/M 

redirect ion- reason 

M 

M/M 

M/M 

ORName 

address 

M 

M/M 

M/M 

standard- at tributes 

M 

M/M 

M/M 

country -name 

0 

M/M 

0/M 

CountryName 

administration- domain-name 

0 

M/M 

0/M 

DomainName 

network- address 

0 

M/M 

0/M 

8-34 


December  '89 


MTS  Transfer  Protocoi  (Pi) 

Part     8  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments /References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

terminal- identifier 

0 

M/M 

0/M 

pr  ivate - domain-name 

0 

M/M 

0/M 

riomp  1  TiN^mp 

U\JHICL  J-  L  Lll  exilic 

organization- name 

0 

M/M 

0/M 

numeric-user- identifier 

0 

M/M 

0/M 

personal -name 

0 

M/M 

0/M 

surname 

M 

M/M 

M/M 

given-name 

0 

M/M 

0/M 

initials 

0 

M/M 

0/M 

generation- qualifier 

0 

M/M 

0/M 

organizational -unit -names 

0 

M/M 

0/M 

OrganizationUnitName 

M 

M/M 

0/M 

domain- defined- at tributes 

0 

M/M 

0/M 

DomainDefinedAt tribute 

M 

M/M 

0/M 

type 

M 

M/M 

M/M 

value 

M 

M/M 

M/M 

extension- attributes 

0 

0/M 

0/M 

Ext ens  ionAt tribute 

common -name 

0 

0/M 

0/M 

teletex- common- name 

0 

0/M 

0/M 

teletex- organization -name 

0 

0/M 

0/M 

teletex -personal -name 

0 

0/M 

0/M 

te letex- organizational -unit - 

names 

0 

0/M 

0/M 

te letex- domain- defined- 

attributes 

0 

0/M 

0/M 

pds-name 

0 

0/M 

0/M 

physical -de livery -country- 

name 

0 

0/M 

0/M 

postal-code 

0 

0/M 

0/M 

physical-delivery-off ice -name 

0 

0/M 

0/M 

physical-delivery-of f ice- 

number 

0 

0/M 

0/M 

extension- OR- address - 

components 

0 

0/M 

0/M 

physical -de live ry-personal- 

name 

0 

0/M 

0/M 

physical-delivery- 

organizat ion- name 

0 

0/M 

0/M 

extension-physical -de livery- 

address  -components 

0 

0/M 

0/M 

unformatted- postal -address 

0 

0/M 

0/M 

street-address 

0 

0/M 

0/M 

post-office -box -address 

0 

0/M 

0/M 

pos te - re stante- address 

0 

0/M 

0/M 
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MTS  Transfer  Protocol  (Pi) 

Part    9  of  9 

MT  Kernel  Support  by  MTS  Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

im  1  fiup  -  no   t"  a  1  -namp 

0 

0 /M 

0 /M 

1      O  O  1  —     rto^ol  —  a^^VT  Vm  1  t"  q  o 
XOCclX    pUoLdX    cl  U  L  L  J.  UU.  L.6  o 

n  /M 

/  11 

extended- network- address 

0 

0/M 

0/M 

terminal -  type 

0 

0/M 

0/M 

rli  Tpr*  t"OT*v - nflmp 

0 

0 /o 

0 /o 

Ex tens ionAt tribute 

extension- at tribute  -  type 

M 

M/M 

M/M 

cxcens ion  acL-cj-Duce  va j.ue 

M 

Sri 

M  /M 
CL/ 11 

M  /M 

11  /  n 

GlobalDoraainldentif ier 

country-name 

M 

M/M 

M/M 

CountryName 

administration- domain- name 

M 

M/M 

M/M 

DomainName 

private-domain- identifier 

0 

M/M 

0/M 

DomainName 

CountryName 

xl21 -dec-code 

0 

0/M 

0/M 

iso-3166-alpha2-code 

0 

M/M 

0/M 

DomainName 

numeric 

0 

0/M 

0/M 

printable 

0 

M/M 

0/M 

Notes  (continued) : 

3)      An  implementation  is  only  required  to 

generate  EITs  that 

correspond  to  the  body  parts  it  is  capable  of  generating. 
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8.17.2      Interpersonal  Messaging  Protocol  (P2) 


Table  8.26.     Classification  of  the  P2  Protocol  Elements 


Interpersonal  Messaging  Protocol 

(P2) 

Part  1  of  3 

Support  by 

UA 

Protocol  Element 

S 

0/R 

Comments/References 

Inf ormationObj  act 

ipm 

0 

M/M 

IPM 

ipn 

0 

M/M 

IPN  -  see  Note  4 

IPM 

heading 

M 

M/M 

this -IPM 

M 

M/M 

IPMIdentif ier 

originator 

0 

M/M 

ORDescriptor 

author izing-users 

0 

0/M 

Recipient Spec if ier 

primary- recipients 

0 

M/M 

RecipientSpecif ier 

copy- recipients 

0 

M/M 

RecipientSpeclf ier 

blind- copy- recipients 

0 

0/M 

RecipientSpecif ier 

replied- to- IPM 

0 

M/M 

IPMIdentif ier 

obsoleted-IPMs 

0 

0/M 

IPMIdentif ier 

related-IPMs 

0 

0/M 

IPMIdentif ier 

subj  ect 

0 

M/M 

See  Note  1 , 

8 

expiry- time 

0 

0/M 

reply- time 

0 

0/M 

reply- recipients 

0 

0/M 

ORDescriptor 

importance 

0 

0/M 

sensitivity 

0 

0/M 

auto -  forwarded 

0 

0/M 

extensions 

0 

0/M 

HeadingExtens  ion 

incomplete -copy 

0 

0/0 

languages 

0 

0/M 

body 

M 

M/M 

BodyPart 

IPN 

common- fields 

M 

M/M 

subj ect- ipm 

M 

M/M 

ipn-originator 

0 

M/M 

ORDescriptor 

ipm-preferred- recipient 

0 

M/M 

ORDescriptor 

conversion-eits 

0 

0/M 

Encodedinf ormationTypes 

non- receipt- fields 

0 

M/M 

See  Note  5 

non- receipt- reason 

M 

M/M 

discard- reason 

0 

M/M 

auto -  forward- comment 

0 

0/M 

returned- ipm 

0 

0/0 

See  Note  2 

receipt-fields 

0 

0/M 

receipt- time 

M 

M/M 
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Interpersonal  Messaging  Protocol 

(P2) 

Part  2  of  3 

Support  by 

UA 

Protocol  Element 

S 

0/R 

Comments/References 

acknowledgment -mode 

0 

0/M 

suppl- receipt -info 

0 

0/0 

HeadingExtension 

type 

M 

M/M 

value 

M 

M/M 

IPMIdentifier 

user 

0 

0/M 

user- relative- identifier 

M 

M/M 

ORDescriptor 

formal -name 

0 

0/M 

ORName  -  see  Note  3 

free -form- name 

0 

0/M 

See  Note  8 

telephone -number 

0 

0/M 

Recipient Specifier 

recipient 

M 

M/M 

ORDescriptor 

notification- requests 

0 

0/M 

reply- requested 

0 

0/M 

BodyPart 

ia5- text 

0 

M/M 

parameters 

M 

M/M 

repertoire 

0 

0/M 

See  Note  6 

data 

M 

M/M 

voice 

0 

* 

See  Note  7 

g3-facsimile 

0 

0/0 

parameters 

M 

M/M 

number -of -pages 

0 

0/M 

non-basic -parameters 

0 

0/M 

data 

M 

M/M 

g4-classl 

0 

0/0 

teletex 

0 

0/0 

parameters 

M 

M/M 

number- of -pages 

0 

0/0 

telex- compatible 

0 

0/0 

non-basic -parameters 

0 

0/0 

data 

M 

M/M 

videotex 

0 

0/0 

parameters 

M 

M/M 

syntax 

0 

0/M 

data 

M 

M/M 

encrypted 

0 

* 

See  Note  7 
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Interpersonal  Messaging  Protocol  (P2) 


Part  3  of  3 


Protocol  Element 


Support  by 
UA 
0/R 


Comments /References 


message 
parameters 
delivery- time 
de 1 ive  ry - enve lope 

data 
mixed-mode 
bilaterally -defined 
nationally- defined 
externally- defined 

parameters 

data 

GeneralTextBodyPart 


0/M 
M/M 
0/M 
0/M 

M/M 
0/0 
0/0 
0/0 
0/M 
M/M 
M/M 


See  P3  OtherMessage 
DeliveryFields 


Notes : 

1)  The  ability  to  generate  the  maximum  size  subject  is  not 
required. 

2)  May  only  be  included  if  specifically  requested  by  the 
originator . 

3)  The  ORNarae  should  be  specified  wherever  possible. 

4)  The  ability  to  generate  an  IPN  is  optional  in  the  case  of 
an  implementation  in  which  a  non-receipt  condition  cannot 
occur  and  receipt  notification  is  not  supported  (see 
table  8.5) . 

5)  The  ability  to  generate  non-receipt-fields  is  optional  in 
the  case  of  an  implementation  in  which  a  non-receipt 
condition  cannot  occur  (see  Note  4). 

6)  Only  the  IA5  repertoire  has  to  be  supported  for  an  ia5-text 
body  part  on  reception. 

7)  The  definition  of  these  body  parts  is  for  further  study  in 
CCITT  and  ISO. 

8)  Only  the  IA5  subset  of  the  T.61  character  repertoire  need 
be  generated.  All  T.61  characters  should  be  supported  on 
reception. 
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8. 17.3      MTS  Access  Protocol  (P3) 

Note:  The  support  classifications  for  the  IPM  UA,  MS  and  MTA  below 

indicate  the  minimum  level  of  support  required  by 
implementations  conforming  to  these  Agreements,  and  should 
not  be  misconstrued  as  a  redefinition  of  any  of  the  MHS 
application  contexts. 


Table  8.27.     Classification  of  the  P3  Protocol  Elements 


MTS  Access  Protocol  (P3) 

Part    1  of  10 

Support  by: 

T  PM 

1  rfl 

UA 

0/R 

MS 
0/R 

MTA 

0/R 

Protocol  Element 

S 

Comments /References 

Operations 

MTSBind 
MTSUnbind 

M 
M 

M/M 

M/M 

yjf  /\jf 

M/M 

M/M 
M/M 

MTSBind 

MSSE 

message -submission 
probe -submission 
cancel -defer red- delivery 
submission- control 

M 
M 
M 
M 

M/- 
0/- 

0/- 

-/M 

M/M 
M/M 
M/M 
M/M 

-/M 
-/M 
-/M 
0/- 

MessageSubmission 
ProbeSubmission 
CancelDeferredDe livery 
SubmissionControl 

MDSE 

mess age -de livery 
report -de livery 
de 1 ivery - contro 1 

M 
M 
M 

-/M 
-/M 
0/- 

M/M 
M/M 
0/- 

M/- 
M/- 
-/M 

MessageDe livery 
ReportDelive ry 
DeliveryControl 

MASE 
register 

change -credentials 

(MTS  to  MTSuser) 
(MTSuser  to  MTS) 

M 

M 
M 

0/- 

-/M 
0/- 

M/M 

M/M 
M/M 

-/M 

0/- 
-/M 

Register 

ChangeCredentials 
ChangeCredentials 

Note:     A  Message  Store  must  pass 
unaltered. 

through  all  MSSE  and  MASE  operations 
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MTS  Access  Protocol  (P3) 

Part    2  of  10 

Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/References 

Arguments/Results 

MTSBind 

MTS  to  MTS  User 

ARGUMENT 

initiator -name 

M 

-/M 

-/M 

M/- 

mTS-user 

-/- 

-/- 

-/- 

mTA 

0 

-/O 

-/M 

M/- 

isMes sage Store 

-/- 

-/- 

-/- 

messages -waiting 

0 

-/O 

-/O 

0/- 

initiator -credentials 

M 

-/M 

-/M 

M/- 

simple 

0 

-/M 

-/M 

M/- 

strong 

0 

-/O 

-/O 

0/- 

security -context 

0 

-/O 

-/O 

0/- 

1-256 

RESULT 

responder-name 

M 

M/- 

M/- 

-/M 

mTS-user 

0 

M/- 

M/- 

-/M 

mTA 

-/- 

-/- 

-/- 

isMessageStore 

0 

M/- 

M/- 

-/M 

messages -waiting 

-/- 

-/- 

-/- 

responder- credentials 

M 

M/- 

M/- 

-/M 

simple 

0 

M/- 

M/- 

-/M 

strong 

0 

0/- 

0/- 

-/O 

MTSBind 

MTS  User  to  MTS 

ARGUMENT 

initiator -name 

M 

M/- 

M/- 

-/M 

mTS-user 

0 

M/- 

M/- 

-/M 

mTA 

-/- 

-/- 

-/- 

isMessageStore 

0 

M/M 

M/- 

-/M 

messages -waiting 

-/- 

-/- 

-/- 

initiator -credentials 

M 

M/- 

M/- 

-/M 

simple 

0 

M/- 

M/- 

-/M 

strong 

0 

0/- 

0/- 

-/O 

security- context 

0 

u/ 

1-256 

RESULT 

responder-name 

M 

-/M 

-/M 

M/- 

mTS-user 

-/- 

-/- 

-/- 

mTA 

0 

-/M 

-/M 

M/- 

isMessageStore 

-/- 

-/- 

messages -waiting 

0 

-/O 

-/O 

0/- 

responder-credentials 

M 

-/M 

-/M 

M/- 

simple 

0 

-/M 

-/M 

M/- 

strong 

0 

-/O 

-/O 

0/- 
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MTS  Access  Protocol  (P3) 

Part    3  of  10 

Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/References 

Message Submission 

ARGUMENT 

M 

M/- 

M/- 

-/M 

MessageSubmission 

Envelope 

contzent 

M 

M/-- 

M/- 

-/M 

RESULT 

mficQacTp-  QiiHmi  QQi  on  —  i  Hp"nt~i  "Pi 

M 

-/M 

-/M 

M/- 

See  PI  MTSIdentif ier 

mp^s^app  -  ^tihim  "i  s*?!  on-t"imp 

111^  *i9  h3  dL  E.^>        u        1-/  111  J-               J_  \^  L  L        ^  JL  IIIV^ 

M 

-/M 

-/M 

M/- 

content- identifier 

0 

-/M 

-/M 

M/- 

extensions 

0 

-/O 

-/O 

0/- 

originating-MTA- certificate 

0 

-/O 

-/O 

0/- 

nt'riO'F-n'F  -  €;i ibm i  q q i  on 

0 

-/O 

-/O 

0/- 

ProbeSubmission 

ARGUMENT 

enve 1 one 

M 

M/- 

M/- 

-/M 

ProbeSubmission 

Envelope 

RESULT 

probe-submission- identifier 

M 

-/M 

-/M 

M/- 

See  PI  MTSIdentif ier 

probe -submission- time 

M 

-/M 

-/M 

M/- 

content- identifier 

0 

-/M 

-/M 

M/- 

CancelDeferredDe livery 

ARGUMENT 

mpqcapp  -  Qiibm  1  's'jion-i  dpn  1 1  f  i  p  r 

liL       J       U.  E.^'                  L-/  til  J-       ij  A.  \^  LI       -1-            L  1       J.  J_  J-  i- 

M 

M/- 

M/- 

-/M 

See  PI  MTSIdentifier 

Submiss  ionControl 

ARGUMENT 

contro Is 

M 

-/M 

-/M 

M/- 

See  Note  1 

n 

-/M 

-/M 

0/- 

permissible -operations 

0 

-/M 

-/M 

0/- 

pe rmi s s ible- maximum -con tent - 

length 

0 

-/M 

-/M 

0/- 

permissible- lowest-priority 

0 

-/M 

-/M 

0/- 

permissible -security -context 

0 

-/O 

-/O 

0/- 

RESULT 

waiting 

M 

M/- 

M/- 

-/M 

See  Note  2 

waiting- operations 

0 

0/- 

0/- 

-/M 

0-16 

wa  i  t  ing -messages 

0 

0/- 

0/- 

-/M 

waiting-content- types 

0 

0/- 

0/- 

-/M 

0-1024 

waiting-encoded- information- 

See  PI  Encoded 

types 

0 

0/- 

0/- 

-/M 

InformationTypes 
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MTS  Access  Protocol  (P3) 

Part    4  of  10 

Support  by: 

IPM 

UA 

MS 

MTA 

Protocol  Element 

b 

0/R 

0/R 

0/R 

Comments/References 

Me ssageDe livery 

ARGUMENT 

envelope 

n 

-  /M 

-  /M 

M/- 

MessageDe livery Enve lope 

content 

n 

-/M 

-/M 

M/- 

rec  ipi ent- cer t i f i cate 

r\ 
V 

0/- 

0/- 

-/O 

prooL  ot  (le i.  1  ve r y 

A 

\J 

0/- 

0/- 

-/O 

ivcpo  x7  L-jjexxvery 

ARPTTMT7MT 

enve lope 

M 

n. 

-/M 

-/M 

M/- 

ReportDeliveryEnvelope 

re turned- content 

U 

-/M 

-/M 

0/- 

De 1 iveryContro  i 

AKGUnhilN  i 

y-t  y-^  •»->  ■f"  V*        1  O 

M 

LI 

M/- 

M/- 

-/M 

See  Note  3 

ire s  L.L  ic  L 

o 

0/- 

0/- 

-/M 

pcLlIliS S  i- U  Xc^    ope L  cl  U XUIlb 

0/- 

0/- 

-/M 

permi s s i d j.e  maximum  concenc 

length 

U 

0/- 

0/- 

-/M 

permissible- lowest -priority 

0 

0/- 

0/- 

-/M 

permissible -content -types 

0 

0/- 

0/- 

-/M 

permi  s  s  i.  □  j.e  encocicci 

See  PI  Encoded 

information- types 

U 

0/- 

0/- 

-/M 

Inf ormat ionTypes 

permiss  ible -  security- context 

u 

0/- 

0/- 

-/O 

D  IT  OTTT  T" 
KtibULi 

waiting 

M 

-/M 

-/M 

M/- 

See  Note  4 

wait ing- operations 

VJ 

-/M 

-/M 

0/- 

waiting -mess ages 

r\ 
U 

-/M 

-/M 

0/- 

wait ing- content -  types 

-/M 

-/M 

0/- 

wait ing- encoded- information- 

See  PI  Encoded 

types 

0 

-/M 

-/M 

0/- 

I nf o  rma  t  i  onTyp  e  s 

Register 

See  Note 

5 

ARGUMENT 

user -name 

0 

0/- 

0/- 

-/O 

See  X.411,  8.4.1.1.1.1 

user-address 

0 

0/- 

0/- 

-/O 

deliverable-encoded- 

See  PI  Encoded 

inf ormat ion- types 

0 

0/- 

M/- 

-/M 

Inf ormat ionTypes 

deliverable -maximum- content - 

length 

0 

0/- 

M/- 

-/M 

de  f aul t - de 1 ive  ry -controls 

0 

0/- 

0/- 

-/M 

restrict 

0 

0/- 

0/- 

-/M 
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MTS  Access  Protocol  (P3) 

Part    5  of  10 

Support  by: 

T  DM 

TTA 

MTA 

Uri 

illf\ 

Protocol  Element 

S 

U/K 

U/K 

U/K 

Comments/References 

permissible -operations 

0 

0/- 

0/- 

-  /M 

permiss  ible - maximum -con tent - 

length 

0 

0/- 

0/- 

-/M 

permissible- lowest -priority 

0 

0/- 

0/- 

-/M 

permiss ible -content- types 

0 

0/- 

0/- 

-/M 

1-1024 

permissible-encoded- 

See  PI  Encoded 

informat ion- types 

0 

U/- 

U/- 

-/M 

Inf ormationTypes 

deliverable -content -types 

0 

-  /M 

1-1024 

labels -and- redirect ions 

0 

1-256 

user- security- label 

0 

n  /- 

recipient- ass  igned- al ternate - 

recipient 

0 

0/- 

0/- 

-/O 

ChangeCredentials 

MTS  to  MTSuser 

ARGUMENT 

old- credentials 

M 

-  /M 

simple 

0 

-  /M 

-  /M 

0/- 

strong 

0 

-  /O 

-  /O 

0/- 

new- credentials 

M 

-  /M 

-  /M 

M  /- 

simple 

0 

-  /M 

-  /M 

0/- 

strong 

0 

-/O 

-/O 

0/- 

ChangeCredentials 

MTSuser  to  MTS 

ARGUMENT 

old- credentials 

M 

M  /- 

M  /- 

-  /M 

simple 

0 

n/- 

-  /M 

strong 

0 

0/- 

0/- 

-  /O 

new- credentials 

M 

M/- 

M/- 

-  /M 

simple 

0 

0/- 

0/- 

-  /M 

strong 

0 

0/- 

0/- 

-  /O 

Mes sage SubmissionEnve lope 

See  Note  6 

\J  1-  ^  tL  A.  L  LCL           1^  LlCXlll^ 

M 

M/- 

M/- 

-/M 

See  PI  ORName 

original-encoded- information- 

See  PI  Encoded 

types 

0 

M/- 

M/- 

-/M 

Inf ormationTypes 

content- type 

M 

M/- 

M/- 

-/M 

built-in 

0 

0/- 

M/- 

-/M 

external 

0 

0/- 

M/- 

-/M 

content- identifier 

0 

0/- 

M/- 

-/M 

1-16 

priority 

0 

M/- 

M/- 

-/M 

All  values 

per -message- indicators 

0 

M/- 

M/- 

-/M 

disclosure -of- recipients 

0 

0/- 

M/- 

-/M 
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MTS  Access  Protocol  (P3) 

Part    6  of  10 

Support  by: 

TPM 

J.  LLl 

TTA 

no 

MTA 
ill  A 

Protocol  Element 

S 

\J  /  IS. 

n  /R 

n  /R 

V^/  IS. 

implicit- conversion-prohibited 

0 

M/- 

/M 

-/M 

alternate -recipient- allowed 

0 

M/- 

M/- 

-  /M 
/n 

content- re turn- request 

0 

0/- 

M/- 

-  /M 

deferred-delivery- time 

0 

M/- 

M/- 

-  /M 

extensions 

0 

M/- 

M/- 

-  /M 

recipient- reassignment- 

prohibited 

0 

0/- 

M/- 

-/M 

dl - expans  ion-prohib  i  ted 

0 

M/- 

M/- 

"/ 

-  /M 

conversion-with-loss- 

prohibited 

0 

0/- 

M/- 
n/ 

-  /M 

latest- del i ve  ry - 1  ime 

0 

n/ 

-  /M 
/n 

originator- re turn- address 

0 

M  /- 

n/- 

-  /M 

-/n 

originator- certificate 

0 

n/- 

n/- 

-  /n 

content- confidentiality- 

algorithm-  identifier 

0 

r>  /- 

-  /n 

message -origin- 

authentication-  check 

0 

0/- 

0/- 

-  /O 

message -security- label 

0 

0/- 

0/- 

-/O 

proof-of- submission- request 

0 

0/- 

0/- 

-/o 

content-correlator 

0 

0/- 

M/- 

-/M 

forwarding- request 

0 

0/- 

M/- 

-  /M 

MS  Abstract  Service  only 

PerRecipientMessageSubmission 

Fields 

M 

M/- 

M/- 

-  /M 

1-32767 

recipient -name 

M 

M/- 

M/- 

-  /M 

See  PI  ORName 

originator -report- request 

M 

M/- 

M/- 

-  /M 

explicit- conversion 

0 

0/- 

M/- 

-  /M 

extensions 

0 

M/- 

M/- 

-  /M 

originator-requested- 

alternate- recipient 

0 

0/- 

0/- 

re que  s  ted- de 1 ivery - me  thod 

0 

M/- 

M/- 
11/ 

-  /M 

physical-forwarding- 

prohibited 

0 

0/- 

M/- 

-/M 

phys ical- forwarding- address - 

request 

0 

0/- 

0/- 

phys ical -de livery-modes 

0 

0/- 

0/- 

-/o 

registered-mail- type 

0 

0/- 

0/- 

-/o 

recipient -number -for -advice 

0 

0/- 

0/- 

-/o 

phys ical -rendition- at tributes 

0 

0/- 

0/- 

-/o 

phys ical -delivery- report- 

request 

0 

0/- 

0/- 

-/o 

message -  token 

0 

0/- 

0/- 

-/o 

content- integrity-check 

0 

0/- 

0/- 

-/o 

proof -of -de livery- request 

0 

0/- 

0/- 

-/o 
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MTS  Access  Protocol  (P3) 

Part    7  of  10 

Support  by: 

TPM 

TTA 

MTA 

uri. 

Protocol  Element 

S 

\J  /  is. 

n  /R 

\J/  IS. 

Comments /References 

ProbeSubmissionEnvelope 

See  Note  6 

originator -name 

M 

n/- 

M  /- 

-  /M 

See  PI  ORName 

original -encoded- information- 

See  PI  Encoded 

types 

0 

M  /- 

/ra 

Inf ormationTypes 

content- type 

M 

M/- 

M/- 

-/M 

built-in 

0 

/ra 

0-32767 

external 

0 

u/  - 

M  /- 

/ra 

content- identifier 

0 

n/- 

M/- 

-  /M 

/n 

1-16 

content- length 

0 

M/- 

M/- 

-/M 

0-'7FFFFFF'H 

per-message- indicators 

0 

M/- 

-/M 

implicit- conversion-prohibited 

0 

M/- 

M/- 

-  /M 
/ri 

alternate -recipient -allowed 

0 

U/- 

n/- 

-/M 

extensions 

0 

M/- 

M/- 

-  /M 
/^i 

recipient -reassignment- 

prohibited 

0 

n  /- 
U/- 

-/ra 

dl- expansion-prohibited 

0 

ra/ 

-  /M 

/ra 

conversion-with-loss- 

prohibited 

0 

-  /M 

/ra 

originator -certificate 

0 

message -security- label 

0 

0/- 

0/- 

-  /O 

content -correlator 

0 

-  /M 

/ra 

probe -origin- authentication- 

check 

0 

n/- 

0/- 

-  /o 

PerRecipientProbeSubmission 

r  xe xus 

n 

M/- 

M/- 

-  /M 
/n 

1-32767 

recipient -name 

M 

M/- 

M/- 

-/M 

See  PI  ORName 

originator- report- request 

M 

M/- 

M/- 

-/M 

explicit- conversion 

0 

M/- 

n/ 

-  /M 

/ra 

0-256 

extensions 

0 

-  /M 

/ra 

originator -reques ted- 

alternate -recipient 

0 

n/- 

n /- 

-  /o 

reques ted- delivery-method 

0 

ra/- 

_  /M 

-/ra 

0-256 

physical -rendition- attributes 

0 

u/- 

-  /M 

See  Note  7 

message-delivery- identifier 

M 

-/M 

-/M 

M/- 

See  PI  MTSIdentifier 

message-delivery- time 

M 

-/M 

-/M 

M/- 

other-fields 

M 

-/M 

-/M 

M/- 

content- type 

M 

-/M 

-/M 

M/- 

built-in 

0 

-/M 

-/M 

M/- 

0-32767 

external 

0 

-/M 

-/M 

M/- 

originator-name 

M 

-/M 

-/M 

M/- 

See  PI  ORName 
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MTS  Access  Protocol  (P3) 

Part     8  of  10 

Support  by: 

IPM 
UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/References 

original-encoded- information- 

See  PI  Encoded 

types 

0 

-/M 

-/M 

M/- 

Inf ormationTypes 

priority 

0 

-/M 

-/M 

M/- 

All  values 

delivery- flags 

0 

-/M 

-/M 

M/- 

implicit -conversion- 

prohibited 

0 

-/M 

-/M 

M/- 

other -recipient-names 

0 

-/M 

-/M 

M/- 

See  PI  ORName 

this -recipient -name 

M 

-/M 

-/M 

M/- 

See  Pi  ORName 

originally- intended-recipient- 

name 

0 

-/M 

-/M 

M/- 

See  PI  ORName 

converted-encoded- information- 

See  PI  Encoded 

types 

0 

-/M 

-/M 

M/- 

Inf ormationTypes 

message -submission- time 

M 

-/M 

-/M 

M/- 

content- identifier 

0 

-/M 

-/M 

M/- 

1-16 

extensions 

0 

-/M 

-/M 

M/- 

conversion-with- loss- 

prohibited 

0 

-/M 

-/M 

M/- 

requested- delivery -method 

0 

-/M 

-/M 

M/- 

physical-forwar ding- 

prohibited 

0 

-/M 

-/M 

M/- 

phys  ical -  forwarding- addres  s - 

request 

0 

-/M 

-/M 

M/- 

phys ical -de livery -modes 

0 

-/M 

-/M 

M/- 

0-16 

registered- mail- type 

0 

-/M 

-/M 

M/- 

0-256 

recipient -number -for -advice 

0 

-/M 

-/M 

M/- 

1-32 

phys ical -rendition- at tributes 

0 

-/M 

-/M 

M/- 

phys ical -de livery- report- 

request 

0 

-/M 

-/M 

M/- 

0-256 

originator- re turn- address 

0 

-/M 

-/M 

M/- 

originator -certificate 

0 

-/O 

-/O 

0/- 

message- token 

0 

-/O 

-/O 

0/- 

content -confidentiality- 

algorithm-  identifier 

0 

-/O 

-/O 

0/- 

content- integrity-check 

0 

-/O 

-/O 

0/- 

message -origin- 

authentication-  check 

0 

-/O 

-/O 

0/- 

message-security- label 

0 

-/o 

-/O 

0/- 

proof- of- delivery- request 

0 

-/O 

-/O 

0/- 

redirection-history 

0 

-/M 

-/M 

M/- 

1-512 

dl - expans  ion-his  tory 

0 

-/M 

-/M 

M/- 

1-512 
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MTS  Access  Protocol  (P3) 

Part    9  of  10 

Support  by: 

IPM 

ITA 

HD 

MTA 

Protocol  Element 

S 

0 /R 

0 /R 

0 /R 

Comments/References 

ReportDe livery Envelope 

See  Note  7 

subj  ect- submission- identifier 

M 

-  /M 

-  /M 

ra/ 

See  PI  MTSIdentif ier 

content- identifier 

0 

-  /M 

/ra 

ra/ 

content- type 

0 

-  /M 

-  /M 

M/- 

built-in 

0 

-  /M 

-  /M 

M/- 
'•V 

0-32767 

external 

0 

-/M 

-/M 

M/- 

original -encoded- information- 

See  PI  Encoded 

types 

0 

-  /M 

-  /M 

M/- 

InformationTypes 

extensions 

0 

-  /M 

-  /M 

M/- 

message -security- label 

0 

-  /O 
/  ^ 

0/- 

content -correlator 

0 

-  /M 

M/- 

originator -and- DL- expansion- 

See  PI  OriginatorAndDL 

history 

0 

-  /M 

-  /M 

M/- 

Exp ans i onH i s t o r y 

reporting-DL-name 

0 

-  /M 

-  /M 

M/- 

reporting-MTA- certificate 

0 

-  /O 

-  /O 

0/- 
^/ 

report -origin- authentication- 

check 

0 

-  /O 

0/- 

PerRecipientReportDe livery - 

Fields 

M 

-  /M 

-  /M 

1-32767 

actual -recipient -name 

M 

-/M 

-  /M 

M/- 

See  PI  ORName 

report 

M 

-  /M 

-  /M 

M/- 

delivery 

0 

-  /M 

-  /M 

M/- 

mess age -de livery -time 

M 

-/M 

-/M 

M/- 

type-of-MTS-user 

0 

-/M 

-/M 

M/- 

non- delivery 

0 

-/M 

-/M 

M/- 

non- delivery- reason- code 

M 

-/M 

-/M 

M/- 

'■'■1 

non- delivery- diagnostic -code 

0 

-/M 

-/M 

M/- 

converted- encoded- information- 

See  PI  Encoded 

types 

0 

-/M 

-/M 

M/- 

InformationTypes 

originally- intended- recipient - 

name 

0 

-/M 

-/M 

M/- 

See  PI  ORName 

supplementary- information 

0 

-/M 

-/M 

M/- 

1-256 

extensions 

0 

-/M 

-/M 

M/- 

redirection-history 

0 

-/M 

-/M 

M/- 

See  PI  Redirection 
History,  1-512 

physical -forwarding -address 

0 

-/M 

-/M 

M/- 

recipient- certificate 

0 

-/O 

-/O 

0/- 

proof -of -delivery 

0 

-/O 

-/O 

0/- 
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Notes : 


Part  10  of  10 


1)       The  MTS-user  may  interpret  any  restriction  as  simply  withhold 
'all'  submissions. 


2)  No  explicit  action  needs  to  be  taken  by  the  MTA. 

3)  The  MTA  may  interpret  any  restriction  as  simply  withhold  'all' 
deliveries . 


4)  No  explicit  action  needs  to  be  taken  by  the  MTS-user. 

5)  The  Register  operation  may  be  performed  locally  (see  X.411). 
Although  not  required  for  the  UA  for  conformance,   it  is 
considered  to  be  a  useful  service  and  support  is  recommended. 

6)  The  action  to  be  taken  by  a  submitting  MTA  is  as  defined  in 
X.411   (ISO  10021-4).     In  the  absence  of  any  specific  processing 
requirements  for  a  particular  element  in  a  submission  envelope, 
the  action  to  be  taken  is  simply  the  faithful  mapping  of  such 
element  to  the  corresponding  element  of  the  appropriate  transfer 
envelope . 

7)  The  action  to  be  taken  by  a  delivering  MTA  is  as  defined  in  X.411 
(ISO  10021-4) .     In  the  absence  of  any  specific  processing 
requirements  for  a  particular  element  in  a  delivery  envelope,  the 
action  to  be  taken  is  simply  the  creation  of  such  element  from 
the  corresponding  element  of  the  appropriate  transfer  envelope. 
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8.17.4      MS  Access  Protocol  (?7) 


Table  8.28.     Classification  of  the  P7  Protocol  Elements 


MS  Access  Protocol  (P7) 

Part    1  of  6 

Support  by: 

IPM 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Comments/References 

Operations 

MSBind 

M 

M/- 

-/M 

MSBind 

MSUnbind 

M 

M/- 

-/M 

MSSE 

message -submission 

M 

M/- 

-/M 

See  P3  MessageSubmission 

probe -submission 

M 

0/- 

-/M 

See  P3  ProbeSubmission 

cancel -deferred- delivery 

M 

0/- 

-/M 

See  P3  CancelDef erred 

Delivery 

submission- control 

M 

-/M 

M/- 

See  P3  SubmissionControl 

MASE 

register 

M 

0/- 

-/M 

See  P3  Register 

change-credentials  (MS  to  UA) 

n 

See  P3  ChangeCredentials 

change-credentials  (UA  to  MS) 

M 

0/- 

-/M 

See  P3  ChangeCredentials 

MKbti 

summarize 

M 

M/- 

-/M 

Summarize 

list 

M 

JM 

M/- 

-/M 

List 

le  ten 

Sri 

M/- 

-/M 

Fetch 

aeiete 

n 

M/- 

-/M 

Delete 

regis ter-ms 

M 

0/- 

-/M 

Register-MS 

alert 

M 

-/O 

0/- 

Alert 

Arguments/Results 

MSBind 

ARGUMENT 

MSBindArgument 

M 

M/- 

-/M 

initiator -name 

M 

M/- 

-/M 

initiator -credentials 

M 

M/- 

-/M 

simple 

0 

M/- 

-/M 

strong 

0 

0/- 

-/o 

security -context 

0 

0/- 

-/O 

fetch -restrict ions 

0 

0/- 

-/M 

allowed- content -types 

0 

0/- 

-/M 

allowed-EITs 

0 

0/- 

-/M 

maximum- content - length 

0 

0/- 

-/M 

MS -configuration- request 

0 

0/- 

-/M 
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MS  Access  Protocoi  (P7) 

Part     2  of  6 

Support  by: 

IPM 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Comments/Ref erences 

M 
11 

-/M 

M/- 

re spender- credent ials 

M 

n. 

-/M 

M/- 

simple 

U 

-/M 

M/- 

s  t rong 

-/O 

0/- 

available -auto -act ions 

U 

-/M 

M/- 

1-16 

available -attribute  -  types 

U 

-/M 

M/- 

1-1024 

alert- indication 

U 

-/M 

0/- 

content- types  -  supported 

u 

-/M 

M/- 

Suimnar  ize 

SummarizeArgument 

n 

M/- 

-/M 

information-base  -  type 

r\ 
U 

0/- 

-/M 

Inf ormationBase 

selector 

M 

M/- 

-/M 

Selector 

o 

w 

0/- 

-/M 

1-16 

SummarizeResult 

M 

-/M 

M/- 

next 

0 

-/M 

M/- 

count 

M 

n 

-/M 

M/- 

0-'7FFFFFFF'H 

span 

n 
u 

-/M 

M/- 

XL*  WC  is  L. 

M 

-/M 

M/- 

highes t 

M 

n 

-/M 

M/- 

summaries 

r\ 

-/M 

M/- 

1-16 

ausenc 

VJ 

-/M 

M/- 

1-'7FFFFFFF'H 

present 

n 
u 

-/M 

M/- 

1- ' 7FFFFFFF'H 

type 

-/M 

M/- 

value 

ri 

-/M 

M/- 

count 

-/M 

M/- 

List 

ARGUMENT 

ListArgument 

M 

M/- 

-/M 

information-base- type 

0 

0/- 

-/M 

Inf ormationBase 

selector 

M 

M/- 

-/M 

Selector 

requested- attributes 

0 

M/- 

-/M 

At tributeSe lection 

RESULT 

ListResult 

M 

-/M 

M/- 

next 

0 

-/M 

M/- 

requested 

0 

-/M 

M/- 

Entryinf ormation , 

0- '7FFFFFFF'H 
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MS  Access  Protocol  (P7) 

Part    3  of  6 

Support  by: 

IPM 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Comments/References 

Fetch 

ARGUMENT 

FetchArgument 

M 

M/- 

-/M 

information-base - type 

0 

0/- 

-/M 

Inf ormationBase 

item 

M 

M/- 

-/M 

search 

0 

M/- 

-/M 

Selector 

precise 

0 

M/- 

-/M 

requested- at tributes 

0 

M/- 

-/M 

AttributeSe lection 

RESULT 

FetchResult 

M 

-/M 

M/- 

entry- information 

0 

-/M 

M/- 

Entry Information 

list 

0 

-/M 

M/- 

0-'7FFFFFFF'H 

next 

0 

-/M 

M/- 

Delete 

ARGUMENT 

De le teAr gument 

M 

M/- 

-/M 

information -base- type 

0 

0/- 

-/O 

InformationBase 

items 

M 

M/- 

-/M 

selector 

0 

M/- 

-/M 

Selector 

sequence -numbers 

0 

M/- 

-/M 

1-'7FFFFFFF'H 

RESULT 

DeleteResult 

M 

-/M 

M/- 

Register-MS 

ARGUMENT 

Regis ter-MSAr gument 

M 

M/- 

-/M 

auto -act ion- registrations 

0 

0/- 

-/O 

1-1024 

type 

M 

M/- 

-/M 

registration- identifier 

0 

M/- 

-/M 

registration- parameter 

M 

M/- 

-/M 

See  auto  action 

registration  parameters 

auto -act ion- deregistrat ions 

0 

0/- 

-/O 

1-1024 

type 

M 

M/- 

-/M 

registration- identifier 

0 

M/- 

-/M 

list -at tribute -de faults 

0 

M/- 

-/M 

1-1024 

fetch- attribute -de faults 

0 

-  /M 
/ra 

1-1024 

change -credentials 

0 

M/- 

-/M 

old -credentials 

M 

M/- 

-/M 

new- credentials 

M 

M/- 

-/M 

user- security- labels 

0 

0/- 

-/O 

1-256 

RESULT 

Regis ter-MSResult 

M 

-/M 

M/- 
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MS  Access  Protocol  (P7) 

Part    4  of  6 

Support  by: 

IPM 

UA 

MS 

Protocol  Element 

S 

(J/K 

(J/K 

Comments/References 

Alert 

AKbUMhjN  i 

AlertArgument 

M 

-/M 

M/- 

alert- regis trat ion- identifier 

M 

-/M 

M/- 

new- entry 

0 

-/M 

M/- 

Entry Information 

RESULT 

AiertKesui t 

U 

M/- 

-/M 

Auto  Action  Registration 

Parameters 

AutoForwardRegis trat ionParameter 

filter 

0 

0/- 

-/M 

Filter 

auto -  forward- arguments 

M 

M/- 

-/M 

originator -name 

M/- 

-/M 

content- identifier 

(J 

0/- 

-/M 

priority 

U 

0/- 

-/M 

per -mess age  -  indicators 

V 

0/- 

-/M 

See  P3 

defer red- delivery -time 

0 

0/- 

-/M 

extensions 

0 

0/- 

-/M 

See  P3 

per - recipient - fields 

n. 

M/- 

-  /M 

recipient -name 

M 

M/- 

-/M 

originator -report -request 

rl 

M/- 

-/M 

explicit- conversion 

r\ 
U 

0/- 

-/M 

extensions 

U 

0/- 

-/M 

See  P3 

de le  te -  after - auto -  forwarding 

0 

0/- 

-/M 

other -parameters 

0 

0/- 

-/M 

See  Note 

L 

auto -  forwarding- comment 

0 

0/- 

-/M 

cover-note 

0 

u/  - 

-  /M 

this- ipm-pref ix 

0 

0/- 

-/M 

AutoAlertRegis trat ionParameter 

filter 

0 

0/- 

-/M 

Filter 

alert -addresses 

0 

0/- 

-/O 

address 

M 

M/- 

-/M 

alert- qualifier 

0 

0/- 

-/O 

requested- at tributes 

0 

0/- 

-/M 

Attributes elect ion 

Notes : 

1)      The  specified  syntax  of  other 

-parameters  is  for  IPMS  use  only  - 

see  X.413  clause  12.1  and  X 

.420  clause  19.4. 
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MS  Access  Protocol  (P7) 

Part    5  of  6 

Support  by: 

IPM 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Comments /References 

Common  Data  Types 

At tributeSe lection 

type 

M 

M/- 

-/M 

from 

0 

0/- 

-/M 

1-32767 

n 

0/- 

-/M 

1-32767 

AttributeValueAssertlon 

type 

M 

M/- 

-  /M 

value 

M 

M/- 

-/M 

t~  T*"\7T Ti    cifm^  t"  1  on 

ULlL-i-y  i.  lH~\J  L  Ilia  \^  J-W  Ll 

sequence -number 

M 

-/M 

M/- 

attributes 

0 

-/M 

M/- 

1-1024 

type 

M 

-  /M 

M/- 

values 

M 

-/M 

M/- 

Filter 

item 

0 

M/- 

-/M 

Filterltem 

and 

0 

0/- 

-/o 

1-32 

or 

0 

0/- 

-/O 

1-32 

no  t 

0 

0/- 

-/o 

Filterltem 

equality 

0 

M/- 

-/M 

AttributeValueAssertlon 

(Support  is  0  if  ORname) 

c  1 1}-)  c  t"  r  1  n  P  s 

0 

0/- 

-/o 

type 

M 

M/- 

-/M 

strings 

M 

M/- 

-/M 

greater -or -equal 

0 

0/- 

-/M 

AttributeValueAssertlon 

less-or-equal 

0 

0/- 

-/M 

AttributeValueAssertlon 

present 

0 

0/- 

-/M 

Inf ormationBase 

stored-messages 

0 

M/- 

-/M 

inlog 

0 

0/- 

-/O 

outlog 

0 

0/- 

-/O 

Range 

sequence -number - range 

0 

0/- 

-/M 

from 

0 

0/- 

-/M 

to 

0 

0/- 

-/M 
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MS  Access  Protocol  (P7) 

Part     6  of  6 

Support  by: 

IPM 

UA 

0/R 

MS 
0/R 

Protocol  Element 

S 

Comments/References 

creation- time - range 
from 
to 

o  o  o 

0/- 

0/- 

0/- 

/M 

-/M 
-/M 
-/M 

Selector 
child-entries 
range 
filter 
limit 
override 

0 
0 
0 
0 
0 

0/- 
0/- 
0/- 
0/- 
0/- 

-/M 
-/M 
-/M 
-/M 
-/M 

Range 
Filter 
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8.17.5      Message  Store  General  Attribute  Support 


Table  8.29.     Classification  of  the  Message  Store  General  Attributes 


Message  Store  General  Attribute  Support 

Part  1  of  2 

Support  by: 

IPM 

UA 

Rec 

Bas 

MS 

Org 

IPM 

MS 

Org 

Attribute 

S 

Comments/References 

child- sequence -numbers 

M 

M 

M 

M 

content 

n 

M 

M 

M 

content- confidentiality- 

algorithm-  identifier 

U 

U 

U 

r\ 
U 

content -correlator 

0 

U 

U 

rl 

content- identifier 

(J 

U 

u 

M 

M 

content- integrity-check 

0 

0 

0 

0 

content- length 

0 

U 

U 

M 

content -re turned 

0 

0 

0 

M 

content- type 

M 

M 

M 

M 

conversion- with- loss -prohibited 

0 

0 

0 

M 

converted- eits 

0 

0 

0 

M 

creation- time 

M 

M 

M 

delivered- eits 

r\ 
U 

0 

0 

M 

de 1 ivery- flags 

r\ 
U 

U 

M 

dl- expansion-history 

0 

r\ 
U 

U 

Kf 

n. 

entry- status 

M 

M 

M 
11 

M 
11 

entry  type 

M 

M 

Ul 

n 

M 

intended- rec  ip lent -name 

U 

(J 

U 

M 

me  s  s  age - de 1 ivery - enve lope 

M 

M 

M 
i  I 

M 
11 

message-delivery- identifier 

U 

U 

U 

me  s  s  age - de 1 i ve  ry - 1  ime 

0 

0 

0 

n 

mess age -origin- authentication- 

check 

0 

0 

0 

U 

message -security- label 

0 

u 

U 

r\ 
U 

mess age -submission- time 

0 

0 

0 

n 

message- token 

0 

0 

0 

u 

original-eits 

0 

0 

0 

\t 

n 

originator -certificate 

0 

0 

0 

0 

originator -name 

0 

0 

0 

M 

other -recipient -names 

0 

0 

0 

M 

parent -sequence -number 

M 

M 

M 

M 

per -recipient -report -de livery - 

fields 

M 

M 

M 

M 

priority 

0 

0 

0 

M 

proof -of -de livery -request 

0 

0 

0 

0 

redirection-history 

0 

0 

0 

M 

registration- indication 

0 

0 

0 

0 

report- del ivery- enve lope 

M 

M 

M 

M 

report ing-dl -name 

0 

0 

0 

0 

reporting-mta- certificate 

0 

0 

0 

0 
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Message  Store  General  Attribute  Support 

Part  2  of  2 

Support  by: 

IPM 

UA 

Rec 

Bas 

MS 

Org 

IPM 

MS 

Org 

Attribute 

S 

Comments/References 

report -origin- authentication- 
check 

security- classification 

s e quenc e - numb e r 

subj  ect- submission- identifier 

this -recipient-name 

0 
0 
M 
M 
0 

0 
0 
M 
M 
0 

0 
0 
M 
M 
0 

0 
0 
M 
M 
M 

Note:  Enhanced  MS  support  for  optional  Functional  Groups  is  for  further 
study.  Attributes  which  are  relevant  to  these  areas  are  currently 
specified  as  Unsupported. 
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8.17.6      Message  Store  IPM  Attribute  Support 
This  section  is  to  be  read  in  accordance  with  Annex  C  of  X.420  (1988). 


Table  8.30.     Classification  of  the  Message  Store  IPM  Attributes 


Message  Store  IPM  Attribute  Support 

Part  1  of  2 

Support  by: 

T  PM 

D  ^  ^ 

Kec 

T  PM 

i  rii 
Org 

Attribute 

S 

Comments /References 

Summary  Attributes : 

ipm-entry- type 

(J 

U 

M 

M 

1pm- synopsis 

0 

U 

M 

neaaing  AttriDutes . 

aucnor Lz ing  users 

n 

U 

auco  lorwaraeci 

r\ 
\} 

U 

rl 

D J. inci  copy  recxpiencs 

n 
u 

U 

M 

copy- recipients 

u 

U 

M 
11 

expiry- time 

U 

M 

n. 

heading 

M 

M 

M 

importance 

0 

U 

rl 

incomplete -copy 

0 

0 

0 

languages 

U 

0 

M 

nrn- requestors 

0 

0 

M 

obsoleted- ipms 

u 

U 

M. 

ongma  uor 

U 

u 

n 

pi imaLy  recipxents 

u 

U 

M 

n. 

related- ipms 

0 

U 

rl 

replied- to- ipm 

0 

u 

n. 

reply- recipients 

0 

0 

M 

reply- requestors 

0 

0 

M 

reply- time 

0 

0 

M 

rn-requestors 

0 

0 

M 

sensitivity 

0 

0 

M 

subj  ect 

0 

0 

M 

this- ipm 

M 

M 

M 

Body  Attributes: 

b i lateral ly-defined-body- 

parts 

0 

0 

0 

body 

M 

M 

M 

encrypted-body -parts 

0 

0 

0 

encrypted- data 

0 

0 

0 

encrypted -parameters 

0 

0 

0 

extended-body-part- types 

0 

0 

0 
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Message  Store  IPM  Attribute  Support 

Part  2  of  2 

Support  by: 

TPM 

UA 

D  A 

K.ec 

TPM 

1  LiJ 

urg 

Attribute 

oommencs/ Kexerences 

py-^          CL\^  J  A. HI X  X ^      UKJKXy      Lldi.  L. O 

o 

0 

0 

O"  ^  —  TA  OGTTni  1a  —  Hiat"a 

n 

n 

w 

o 
\j 

r\ 
\j 

o 

n 

KJ 

j-d^  ccxt.  Dooy  par ts 

r\ 
U 

w 

M 

o 

w 

n 

1  P  S  —  t"AVf~— TiaT*JiniA'f~AVG 

n 

mA  c  c  S3  0*0  —  r^/^/^'\^  —  T^Q■l^'t~o 

M 

i  1 

TTies  s  A  p'A  -  fi;it~a 

0 

n 

in  e  s  s  a  p"  A  -  "D  a  r  A  ni  A  t"  A  T  Q 

0 

n 

w 

TTIT  VaH— TDoHa  — VioHv  —  TiaT"t*G 

o 

\J 

0 

0 

nationally- defined-body-parts 

0 

0 

0 

teletex-body-parts 

0 

0 

0 

[.c  i.c  cc A  aaca 

KJ 

0 

0 

UCi.C?L.t?A     LF  Ct  1.  dliiC  I.  C  X.  o 

w 

0 

0 

■\T1     o          V  —  r\rt /1\r  —     Q    f"  e 

u 

V laeo  cex  aaca 

u 

w 

rj 
\j 

vyj  i.\^xi    u\j  u>  y    LI  ct  I.  L.  o 

u 

voice -data 

0 

w 

Nnf"i 'Fi  pfl  t"  1  on  Af"l"T"i  hiit"<=>e! ' 

\I  \r  -1.  1-  A.  ^  d      X  V 1  i     ii      ^  X.  X  U  U  ^      O  . 

acknowledgment -mode 

0 

0 

M 

auto -  forward- comment 

0 

0 

M 

conversion-eits 

0 

0 

M 

discard- reason 

0 

0 

M 

ipm-pref erred- recipient 

0 

0 

M 

ipn- originator 

0 

0 

M 

non- receipt- reason 

0 

0 

M 

receipt- time 

0 

0 

M 

returned- ipm 

0 

0 

0 

subject-ipm 

M 

M 

M 

suppl-receipt- info 

0 

0 

0 
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8. 18  APPENDIX  B:     INTERPRETATION  OF  ELEMENTS  OF  SERVICE 
See  Working  Document. 
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8.19  APPENDIX  C:     RECOMMENDED  PRACTICES 

This  section  provides  guidelines  on  areas  not  addressed  by  the  base 
standards.  These  guidelines  have  been  produced  in  order  to  promote 
awareness  of  interim  solution  to  problems  as  agree  by  members  of  the 
NIST  X.400  SIG.  However  implementors  of  these  recommended  practices 
should  note  that  it  is  not  necessary  to  follow  the  recommended 
practices  when  claiming  conformance  to  these  agreements. 

Implementors  should  also  note  that  future  standardization  by  CCITT  and 
ISO/IEC  on  area  covered  by  this  section  may  result  in  different 
solutions  to  those  proposed  in  this  section. 

8.19.1      Printable  String 

There  are  existing  mail  systems  that  include  a  small  set  of  non- 
Printable  String  characters  in  their  identifiers.     For  these 
systems  to  communicate  with  MHS  systems,   either  for  pass -through 
service  or  delivery  to  MHS  users,   gateways  will  be  employed  to 
encode  these  special  characters  into  a  sequence  of  Printable 
String  characters.     This     conversion  should  be  performed  by  the 
gateway  according  to  a  common  scheme  and  before  insertion  in 
Domain  Defined  Attributes,  which  are  intended  to  carry  electronic 
mail  identifiers.     MHS  UAs  may  also  perform  such  conversions. 

It  is  recommended  that  the  following  symmetrical  encoding  and 
decoding  algorithm  for  non-Printable  String  characters  be 
employed.     The  encoding  algorithm  maps  an  ASCII  representation  to 
a  PrintableString  representation.     Any  non-printable  string 
characters  not  specified  in  table  8.31  are  covered  by  the 
category  "other." 


Table  8.31.     Printable  string  to  ASCII  mapping 


ASCII  Character 

Printable  String  Character 

%  (percent) 

(P) 

(a  (at  sign) 

(a) 

!  (exclamation) 

(b) 

"   (quote  mark) 

(q) 

(underline) 

(u) 

(  (left  paren. ) 

(1) 

)   (right  paren. ) 

(r) 

other 

(3DIGIT) 

where  3DIGIT  has  the  range  000  to  377  and  is  interpreted  as  the  octal 
encoding  of  an  ASCII  character. 
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To  encode  an  ASCII  representation  to  a  PrintableString ,  the  table  and 
the  following  algorithm  should  be  used: 


IF  current  character  is  in  the  encoding 

set  THEN 

encode  the  character  according  to  the 

table  above 

ELSE 

write  the  current  character; 

continue  reading; 

To  decode  a  PrintableString  representation  to  an  ASCII 
representation,   the  table  and  the  following  algorithm  should  be  used: 


IF  current  character  is  not  "("  THEN 

write  character 
ELSE 

{ 

look  ahead  appropriate  characters ; 

IF  composite  characters  are  in  the  above  table  THEN 

decode  per  above  table 
ELSE 

write  current  character; 
) 

continue  reading; 


8 . 19 ■ 2      Rendition  of  lASText 

The  characters  that  may  be  used  in  an  lASString  are  the  graphic 
characters  (including  Space),  control  characters  and  Delete  of 
the  IA5  character  repertoire  ISO  646. 

The  graphic  characters  that  may  be  used  with  a  guaranteed 
rendition  are  those  related  with  positions  2/0  to  2/2,   2/5  to 
3/15,  4/1  to  5/10,  5/15  and  6/1  to  7/10  in  the  basic  7-bit  code 
table . 

The  other  graphic  characters  may  be  used  but  have  no  guaranteed 
rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed 
effect  are  a  subset  consisting  of  the  format  effectors  0/10  (LP) , 
0/12  (FF)  and  0/13  (CR)  provided  they  are  used  in  one  of  the 
following  combinations  as  defined  in  table  8.32. 
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Table  8.32.     Interpretation  of  Format  Effector  Combinations 


Combination 

Interpretation 

CR  LF 
CR  FF 
LF  . .  LF 

to  start  a  new  line 
to  start  a  new  page  (and  line) 
to  show  empty  lines  (always  after  one  of  the 
preceding  combinations) . 

The  other  control  characters  or  the  above  control  characters  in 
different  combinations  may  be  used  but  have  no  guaranteed  effect. 

The  character  Delete  may  occur  but  has  no  guaranteed  effect.  The 
lASString  in  a  P2  IA5Text  BodyPart  represents  a  series  of  lines 
which  may  be  divided  into  pages.     Each  line  should  contain  from  0 
to  80  graphic  characters  for  guaranteed  rendition.     Longer  lines 
may  be  arbitrarily  broken  for  rendition.     Note  that  X.408  states 
that  for  conversion  from  IA5Text  to  Teletex,   the  maximum  line 
length  is  77  characters. 

8.19.3      EDI  Use  of  MHS 


8.19.3.1        Introduction  and  Scope 

This  section  presents  a  carry- forward  of  the  Recommended 
Practices  in  chapter  7  of  the  NIST  Stable  Implementation 
Agreements  for  support  of  EDI  data  transfer  in  an  MHS (1988) 
environment.     These  recommended  practices  outline  an  interim 
procedure  for  use  in  transferring  EDI  transactions  between 
trading  partner  applications  in  order  to  facilitate  further 
MHS  implementation  by  EDI  users.     It  is  the  stated 
objective  of  the  NIST  X.400  SIC  to  migrate  towards  the  CCITT 
target  solution  of  PgDi  once  it  is  defined  (currently 
expected  to  be  completed  by  late  1990) .     The  approach  for 
carrying  EDI  interchanges  over  MHS  systems  as  recommended  in 
this  section  provides  a  mechanism  for  a  smooth  migration  to 
the  target  CCITT  P^di  solution. 

The  scope  of  this  guideline  is  to  describe  specific 
recommended  practices  for  extending  MHS  as  a  data  transfer 
mechanism  between  EDI  applications.     This  interim  solution, 
as  in  the  existing  X. 400(1984)  Agreements,   is  referred  to  as 
the  PO  approach  and  differs  slightly  from  the  European 
solution  which  uses  a  P2  mechanism  to  package  the  EDI  data 
stream.     However,   if  adhered  to,  PO  messages  may  be 
delivered  to  P2  recipients  and  vice -versa,  by  the  MTA  making 
a  minor  envelope  conversion  as  recommended  in  this  section. 
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8.19.3.2  Model 

The  model  used  is  consistent  with  that  defined  in  section 
7.12.5  of  the  Agreements  for  X. 400(1984)  systems,  with 
several  minor  exceptions.     As  before,   the  model  provides  for 
a  peer-to-peer  EDI  Messaging  (EDIM)  UA  service. 


EDI  User 
Application 

EDIM 
UA 

MTS 

EDIM 
UA 

EDI  User 
Application 

Figure  8.11.     EDI  Messaging  Functional  Model. 

In  figure  8.11,  the  EDIM  UA  may  support  delivery  of  EDI 
messages  formatted  according  to  the  NIST  P0(88) ,  P0(84), 
P2(84)  or  P22(88)  Agreements.     It  is  recommended  that 
implementations  supporting  EDI  over  MHS  generate  PO 
formatted  messages  as  described  below,  but  be  prepared  to 
deliver  any  of  the  four  recognized  formats  for  which 
Agreements  have  been  achieved.     Whether  the  EDI  transaction 
is  carried  using  the  PO  or  P2  (88  or  84)  approaches,   the  EDI 
content  is  restricted  to  be  only  one  EDI  interchange  per  MHS 
message.     The  NIST  approach  carries  forward  the  1984  X.400 
recommended  practices  as  a  interim  interworking  solution. 
The  use  of  object  identifiers  in  either  the  EIT  or  Content 
Type  fields  is  not  recommended  due  to  the  current  definition 
of  the  1984  interworking  rules  specified  in  CCITT 
Recommendation  X.419  (see  below). 

The  EDIM  UA  must  support  the  essential  MT  and  MS  Elements  of 
Service  as  defined  in  this  Agreement.  It  is  recognized  that 
a  Message  Store  may  not  convey  much  information  to  a  remote 
EDIM  UA  with  the  PO  approach.  It  is  further  recognized  that 
MS  Elements  of  Service  are  not  necessarily  made  available  by 
the  EDIM  UA  to  the  EDI  user  application. 

8.19.3.3        Protocol  Elements  Supported  for  EDI 

The  following  PI  protocol  elements  will  be  used  as  a  minimum 
to  support  EDI  applications: 

Content  Type 
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For  EDIM  applications,   the  content  type  will  continue  to  be 
as  specified  in  section  7.12,5.3  of  the  NIST  Stable 
Agreements  f or  X. 400 ( 1984) ,   i.e.,  Undefined  (0).  The 
interchange  contained  in  the  PI  envelope  and  identified  by 
this  Content  Type  is  carried  as  an  octet  string. 

Note:      For  interworking  with  1984  X.400  systems,  the 
use  of  an  externally  registered  object 
identifier  is  not  recommended.     Such  use  would 
create  interworking  problems  as  well  as  loss  of 
information  when  the  Z.419  downgrading  rules  are 
applied.     In  the  current  definition  of  the 
latter,  an  object  identifier  would  be  mapped  to 
the  Content  Type  value  of  1  (External) ,  instead 
of  0  (Undefined),     Additionally,  the 
downgrading  rules  require  the  object  identifier 
value  to  be  inserted  into  the  Content,  which 
would  cause  further  interworking  problems  since 
1984  EDIM  UAs  will  expect  only  the  EDI 
interchange  in  the  Content, 

Original  Encoded  Information  Types  (EITs) 

EDIM  applications  will  continue  to  use  the  EITs  as  specified 
in  section  7,12.5.3  of  the  NIST  Stable  Agreements  for 
X. 400(1984),   i.e,,   lASText  and  Undefined  (for  EBCDIC 
encoding).     However,  it  is  recognized  that  any  EIT  defined 
in  the  1988  MHS  standards  may  be  used  to  specify  the 
encodings  of  the  EDI  content. 

Note:      For  interworking  with  1984  X,400  systems,  the 
use  of  an  externally  registered  object 
identifier  to  signify  the  EDI  encoding  is  not 
recommended.     According  to  the  current 
definition  of  the  downgrading  rules  in  CCITT 
Recommendation  X.419,  a  1988  MTA  must  downgrade 
an  object  identifier  to  Undefined  and  then 
discard  the  object  identifier.     Such  loss  of  EDI 
encoding  information  conflicts  with  the  existing 
Agreements  for  X. 400(1984)  systems  that  the 
semantics  of  the  Undefined  EIT  is  always  EBCDIC. 


8.19.3.4        Addressing  and  Routing 

As  in  the  Stable  Implementation  Agreements  for  X, 400(1984), 
EDI  messages  entering  a  1988  MHS  environment  will  need  to 
have  MHS  0/R  Names  and/or  0/R  Addresses  in  the  PI  envelope 
to  identify  the  originator  and  recipient  trading  partners. 
The  mapping  of  the  EDI  originator  and  recipient  interchange 
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addresses  to  an  0/R  Name  or  0/R  Address  may  be  achieved 
either  by  local  means  or  through  services  provided  by  the 
OSI  Directory  (see  sec.  8.9.1). 

If  the  EDI  message  is  originated  and  delivered  without 
transiting  a  X. 400 (1984)  MTA,  then  any  of  the  0/R  Address 
forms  specified  in  this  Agreement  may  be  used.  However, 
since  it  cannot  be  assumed  that  EDI  messages  will  never 
transit  an  X. 400(1984)  MTA,  it  will  often  be  useful  to 
include  additional  Domain  Defined  Attributes  as  specified  in 
section  7.12.5.4  of  the  Stable  Agreements.     This  DDA  is 
needed  to  ensure  that  a  message  is  deliverable  to  an  EDIM  UA 
associated  with  a  X. 400(1984)  MTA  and  that  delivery  and 
receipt  reports  can  be  flagged  as  a  new  report  type. 

8.19.4      Textual  Representation  of  0/R  Names 
I  See  Working  Docuxnent . 

8.20  APPENDIX  D:     LIST  OF  ASN.l  OBJECT  IDENTIFIERS 
I        See  Working  Document. 

8 . 20 ■ 1       Content  Types 
I  See  Working  Document. 

8.20.2      Body  Part  Types 
I  See  Working  Document. 
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9_^  ISO  FILE  TRANSFER.   ACCESS  AND  MANAGEMENT  PHASE  2 

Editor's  Note:  In  document  type  names,  constraint  set  names,  and 
abstract  syntax  definitions,  the  "NBS"  designation 
will  be  preserved. 

9.1  INTRODUCTION 


This  section  defines  Implementors '  Agreements  based  on  ISO  File 
Transfer,  Access  and  Management  (FTAM) ,  as  defined  in  ISO  8571.  This 
International  Standard  has  four  parts.     Part  1  of  the  IS  gives 
general  concepts.   Part  2  defines  the  Virtual  Filestore   (VFS) ,   Part  3 
defines  the  File  Service,  and  Part  4  defines  the  File  Protocol. 

FTAM,  as  described  in  the  IS,   is  based  on  the  following  ISO  documents: 
ACSE  Service  and  Protocol  (ISO  8649,   ISO  8650),   Presentation  Service 
and  Protocol  (ISO  8822,   ISO  8823),  ASN.l  Abstract  Syntax  Notation  and 
Basic  Encoding  Rules   (ISO  8824,   ISO  8825),   and  Session  Service  and 
Protocol  (ISO  8326,   ISO  8327).     These  services  and  protocols  are 
defined  architecturally  in  the  OSI  Reference  Model  (ISO  7498).  These 
Agreements  provide  detailed  guidance  for  the  implementor,  and 
eliminate  ambiguities  in  interpretations. 

The  general  agreements  reached  with  respect  to  the  ISO  File  Transfer, 
Access  and  Management  Protocol  (FTAM)  are  that  the  Phase  2  FTAM 
specification  (this  sec.)   is  based  on  the  International  Standard 
(IS). 

9 . 2     SCOPE  AND  FIELD  OF  APPLICATION 


These  FTAM  Phase  2  Agreements  cover  transfer  of  and  access  to  files 
between  the  Filestores  of  two  end  systems,   including  the  management  of 
a  Virtual  Filestore.     One  end  system  acts  in  the  Initiator  role  and 
initiates  the  file  transfer/access,  while  the  other  end  system  acts  in 
the  Responder  role  and  provides  access  to  the  file  in  the  Virtual 
Filestore.     This  paper  describes  Agreements  for  the  actions  and 
attributes  of  the  Virtual  Filestore,  and  the  service  provided  by  the 
file  service  provider  to  file  service  users,   together  with  the 
necessary  communications  between  the  Initiator  and  Responder. 
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Virtual 
Filestore 
2 


Real 
Filestore 
1 

End 
System  1 
-  Initiator  - 

End 
System  2 
-  Responder  - 

Real 
Filestore 
2 

Figure  9.1.     Model  of  file  transfer/access. 


Note:  Agreements  apply  on  the  double  lines  of  figure  1.  T  h  e 

mapping  between  the  Virtual  Filestore  and  the  Real 
Filestore  together  with  the  local  data  management 
system  is  not  part  of  these  Agreements . 

These  Agreements  define  General  Agreements  in  section  9.5  through 

9.16,  minimum  functionality  (Conformant  Implementations)   in  section 

9.17,  and  functionality  for  several  Implementation  Profiles  which  are 
tailored  to  different  classes  of  user  requirements  in  sections  9.18 
and  9.19. 


9.3  STATUS 


Version  2  of  the  FTAM  Phase  2  Implementation  Agreements  was  completed 
December  16,   1988,  and  published  in  version  2  of  the  Stable 
Implementation  Agreements  (NIST  Special  Publication  500-162,  December 
1988).     Some  editorial  clarifications,  technical  changes  and  alignment 
changes  (due  to  international  harmonization  of  Profiles)  were  added  to 
Version  2  Agreements  in  the  course  of  1989.     All  these  changes  are  now 
fully  incorporated  in  this  version  3  of  the  FTAM  Phase  2  Stable 
Agreements . 

No  further  enhancements  will  be  made  to  this  version  3  of  FTAM  Phase 
2  (see  the  next  sec.  ERRATA). 

This  version  3  of  the  FTAM  Phase  2  Agreements  fully  replaces  the 
version  2  as  published  in  NIST  SP  500-162.     Therefore,   the  old  version 
2  of  FTAM  Phase  2  will  no  longer  be  maintained. 
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The  following  list  summarizes  the  technical  errata  changes  to  FTAM 
Phase  2,  Version  1  which  were  incorporated  in  Version  2.     It  also 
states  the  degree  of  possible  interworking  and  backward  compatibility 
to  FTAM  Phase  2,  Version  1. 


Technical  Changes  in  FTAM  Phase  2, 
Version  2  (Dec.  '88) 


1.  Check  of  already  established 
presentation  contexts  for  a 
document  type  not  at  CREATE 
time  but  at  OPEN  time 

2.  Receivers  shall  not  require 
sending  of  AETtitles 


3 .      Minimum  requirement  for  FADU 
identities  for  document  types 
which  use  the  sequential  flat 
constraint  set 


Backward  Compatibility  to  FTAM 
Phase  2,  Version  1  (Dec.  '87) 


Interworking  problems  could 
occur  when  creating  a 
document  type  which  is  not 
opened. 

Inteirworking  problems  could 
occur  if  AETitles  are  not 
sent 

Interworking  problems  could 
occur  if  FADU  identities 
beyond  the  minimum  requirement 
are  used 


9-3 


March  1990  (Stable) 


The  following  list  sununarizes  the  technical  errata  and  alignment 
changes  which  were  incorporated  in  FTAM  Phase  2,  Version  3.     It  also 
states  the  degree  of  possible  interworking  and  backward  compatibility 
to  FTAM  Phase  2,  Version  2. 


Technical  Changes  in  FTAM  Phase  2, 
Version  3  (Dec.  '89) 


Backward  Compatibility  to  FTAM 
Phase  2,  Version  2  (Dec.  '88) 


Unconstrained  Service  Class 
outside  the  scope  of  the 
Implementation  Profiles. 

<contents- type -lis t>  parameter: 
Both  types  of  values  optional 
for  Initiators 

Specification  of  supported 
values  for  <override> 
parameter  in  F- CREATE 

Parameters  <filesize>,  <future 
files ize>,  <fadu-number>  may  be 
encoded  with  up  to  8  contents 
octets 

For  NBS-7  and  NBS-8  in 
conjunction  with  T  or  TM 
Service  Class,  the  FADU 
identities  "current,"  "next," 
"previous"  are  not  required 

For  NBS-8  files  the  minimum 
range  for  keys  of  string- type 
is  (1-16)  instead  of  (0-16) 

Restriction  "NBS-9  files  may 
not  be  Created  or  Deleted" 
removed  from  the  document  type 
definition.     But  both  actions 
are  outside  the  scope  of  the 
Agreements . 

Constraint  set  NBS-ordered- 
flat:     The  location  after  an 
Insert  is  "end" 


ProftlesT  Full  compatibility, 
since  change  only  from 
"optional"  "to  "outside  scope'' 

Full  compatibility,  since  this 
clarification  is  only  for 
Initiators 

Interworking  problems  may 
occur,  if  different  values 
supported 

Interworking  problems  may 
occur,  since  no  minimum 
requirement  was  defined  for 
Version  2. 

Full  compatibility,  since 
these  identities  were  never 
useful  in  conjunction  with  T 
or  TM  Service  Class 


Interworking  problems  may 
occur  for  key- length  parameter 
0. 

Full  compatibility,  since 
Creation,  Deletion  was  never 
in  the  scope  of  the  Agreements 


Full  compatibility,  since  this 
specification  was  already 
implicitly  clear 
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9.4  ERRATA 


Editor's  Note:  ERRATA 

applicability  information  may 

be  given  here. 

REFERENCED 

NO 

.  OF  ERRATA  TYPE 

DOCUMENT  SECTION 

CP 

3/90-1  TECHNICAL 

NIST-SP  APPENDICES 

NBS-6,  NBS-7, 

500-177               A,  B,  C 

NBS-8,  NBS-9, 

NBS-ASl,  NBS-AS2, 

NBS -ordered- flat 

constraint  set 

with  Obj .  Id. 

using  icd(9999) 

withdrawn. 

Above  FTAM  objects 

newly  defined  with 

Obj .  Id.  using 

oiw(14)  ftamsig(5) 

CP 

3/90-2  EDITORIAL 

9.17.9 

Clarification  that 

INTEGER  encoding 

of  more  than  4 

contents  octets  may 

be  rejected  by 

receiver 

CP 

3/90-3  EDITORIAL 

Appendices  instead 

of  section  9.21, 

structuring  into 

subsections.  All 

references  to  these 

definitions  updated 

accordingly 

CP 

3/90-4  EDITORIAL 

9.3 

New  interworking 

table  for  Phase  2, 

Version  1  and 

Version  2 

CP 

6/90-1  EDITORIAL 

9.1 

Notes  7 ,  8  added 

to  clarify  the 

use  of  Escape 

Sequences 
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9_Ji  ERRATA 

Editor's  Note:  ERRATA  applicability  information  may  be  given  here. 


NO 

OF  ERRATA  TYPE 

REFERENCED 
DOCUMENT 

SECTION 

CP 

1  /QD  1 

TPT'UMT  r  AT 

NIST-SP 
500-i77 

APPENDICES 
A,  B.  C 

NBS-6,  NBS-7, 
NBS-8,  NBS-9, 
NBS-ASl,  NBS-AS2, 
NBS- ordered- flat 
constraint  set 
with  Obj .  Id. 
using  icd(9999) 
withdrawn. 

Above  FT AM  objects 
newlv  defined  with 
Obj .   Id.  using 
oiw(14)  ftamsig(5) 

CP 

3/90-2 

EDITORIAL 

9.17.9 

Clarification  that 
INTEGER  encoding 
of  more  than  4 
contents  octets  may 
be  rejected  by 
receiver 

CP 

3/90-3 

EDITORIAL 

Appendices  instead 
of  section  9.21, 
^ tnif turi n P  into 
subsections.  All 
references  to  these 
definitions  updated 
accordingly 

CP 

3/90-4 

EDITORIAL 

9.3 

New  inter\<7orking 
table  for  Phase  2, 
Version  1  and 
Version  2 

CP 

6/90-1 

EDITORIAL 

Table  9.1 

Notes  7 ,   8  added 
to  clarify  the 
use  of  Escape 
Sequences 
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9.5  ASSUMPTIONS 

1.  FTAM  protocol  machines  must  be  able  to  parse  and  process  at  a 
minimum  7K  octets  of  FTAM  PCI,  FTAM  structuring  (FTAM-FADU)  and 
FTAM  user  data  (including  grouped  FPDUs)  as  they  would  be  encoded 
with  the  ASN.l  Basic  Encoding  Rules.  It  is  recommended,  hov/ever, 
that    Presentation  user  data  not  be  restricted  in  size. 

2.  In  order  to  maximize  interoperability,  it  is  important  that  the 
implementations  of  FTAM  service  providers  do  not  unnecessarily 
restrict  the  service  user's  ability  to  generate  arbitrary  file 
service  requests.  Otherwise,  they  may  not  be  able  to  work  with 
FTAM  Responders  whose  operation  is  constrained  by  their  mapping 
of  the  FTAM  Virtual  Filestore  to  their  local  filestore.  For 
example,  error  procedures  should  only  be  invoked  when  an  error 
actually  occurs,  not  at  the  point  of  the  specification  of 
options  which  might  result  in  an  error, 

3.  Implementations  must  be  able  to  parse  all  valid  optional 
parameters  if  they  are  present  in  the  PDU.  Only  those  optional 
parameters  specified  as  supported  in  these  Agreements  are 
required  to  be  implemented.  If  these  parameters  are  not  present, 
a  default  value  is  assigned  locally.  A  Responder  should  not 
refuse  a  request  solely  because  a  parameter  that  is  optional  in 
the  FTAM  standard,  but  is  supported  in  these  Agreements,  is  not 
present. 

4.  Consideration  of  any  standardized  service  interface  is  not 
covered  by  these  Agreements . 

5.  These  Agreements  define  no  restrictions  for  the  values  used  for 
the  <communication  quality  of  service>  parameter  in  <F- 
INITIALIZE>. 

6.  FTAM  is  defined  in  phases.  The  Phase  1  FTAM  implementation 
specification  is  based  on  the  second  ISO  Draft  Proposal,  dated 
April  1985,  and  the  ISO  Draft  Proposal  8824  and  8825. 

The  Phase  2  FTAM  specification  (this  sec.)  is  based  on  the 
International  Standard  (IS).  THERE  IS  NO  BACKWARD  COMPATIBILITY 
WITH  NIST  FTAM  PHASE  1.  Backward  compatibility  is  impossible, 
since  Phase  1  uses  Session  services  directly,  while  Phase  2  uses 
ACSE     and     Presentation     services.  Furthermore,      there  are 

differences  in  Filestore,  PDU  Abstract  Syntax,  FADU  Abstract 
Syntax,  and  Transfer  Syntax.  There  also  are  differences  in  the 
transparency  mechanisms  and  service  class  negotiations. 

The  <implementation  information>  parameter  of  <F-INITIALIZE>  FPDU 
as  defined  in  ISO  8571-4,  20.3  is  used  to  pass  'user  version' 
information  with  respect  to  different  FTAM  phases  of  the  NIST 
Implementors  Agreements  or  with  respect  to  FTAM  profiles  of  other 
bodies    (see    sec.    9,12    of   this    document).       It    is    the    goal  of 
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these  Agreements  to  use  the  'user  version'  mechanism  to  provide 
at  least  one  level  of  backward  compatibility  for  all  future 
NIST  FTAM  Phases,  facilitating  backward  compatibility  for  future 
FTAM  products,  assuming  different  new  versions  of  the  respective 
IS's  also  enable  backward  compatibility. 

7.  The  FTAM  specific  ASE  requirements  for  ACSE  in  the  Upper  Layers 
chapter  of  this  document  define  a  value  (that  carries  no 
semantics)  for  the  AETitle  that  can  be  used  by  FTAM  ASEs  for 
communication.  Other  values  for  the  AETitle  are  outside  the 
scope  of  these  Agreements. 

The  association  shall  not  be  rej  ected/ aborted  if  any  of  the 
following  parameters  either  contains  the  defined  value  or  is  not 
sent: 

Called  -  AETitle 
Calling  -  AETitle 
Responding  -  AETitle 

The  association  may  be  rejected/aborted  if  any  of  these 
parameters  contain  other  values. 

Use  of  values  outside  the  scope  of  these  Agreements  is 
discouraged  until  agreed  upon  semantics  have  been  associated  with 
AETitles . 

8 .  Use  of  <shared  ASE  information>  parameter  and  <charging> 
parameter  is  not  defined  within  the  scope  of  the  Agreements . 

9.  Use  of  <application  context  name>  parameter  is  not  defined  within 
the  scope  of  these  Agreements.  This  parameter  does  not  prohibit 
the  establishment  of  an  FTAM  association. 

10.  These  Agreements  use  the  term  'supported'  for  a  parameter  to  mean 
that  the  syntax  and  semantics  of  that  parameter  shall  be 
implemented.  However,  it  is  not  a  requirement  that  the  parameter 
be  used  in  all  instances  of  communication,  unless  stated 
otherwise . 

Also  these  Agreements  use  the  term  'optionally  supported'  for  a 
parameter  to  mean  that  it  is  left  to  the  implementation  whether 
the  semantics  of  that  parameter  are  implemented  or  not. 
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9.6  PRESENTATION  AGREEMENTS 

The  following  Abstract  Syntaxes  are  recognized  in  these  agreements: 

"FTAM  FADU" 
"FTAM  PCI" 

"FTAM  unstructured  text  abstract  syntax" 
"FTAM  unstructured  binar}''  abstract  syntax" 
"NBS  abstract  syntax  ASl" 
"NBS  file  directory  entry  abstract  S3mtax" 

The  following  Transfer  Syntax  is  supported: 

"Basic  Encoding  of  a  single  ASN.l  type" 
(See  Appendix  C  Part -3) 

9.7  SERVICE  CLASS  AGREEMENTS 

Implementation  Agreements  have  been  reached  for  the  following  service 
classes . 

o  File  Transfer 

o  File  Access 

o  File  Management 

o  File  Transfer  and  Management 

o  Unconstrained 

9.8  FUNCTIONAL  UNIT  AGREEMENTS 

Implementation  agreements  have  been  reached  for  the  following 
functional  units. 

o  Kernel 

o  Read 

o  Write 

o        File  Access 

o        Limited  File  Management 

o        Enhanced  File  Management 

o  Grouping 

Implementation  of  the  Recovery,  Restart  Data  Transfer,  and  FADU 
Locking  functional  units  is  not  specified. 

9.9  FILE  ATTRIBUTE  AGREEMENTS 

Implementation  of  the  Kernel  Group  of  file  attributes  is  defined.  If 
the  optional  Storage  Group  and  Security  Group  are  implemented, 
aspects  of  their  implementation  are  defined.  Implementation  of  the 
Private  Group  is  not  specified. 
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Responses  to  an  attribute  value  request  shall  always  include  one  of 
the  following  (as  specified  in  ISO  8571-2,  Clause  9.4): 

o        An  actual  file  attribute  value. 

o        A  value  indicating  that  no  value  is  available,  optionally  with  a 
diagnostic . 

o        No  value  and  an  error  code,  optionally  with  a  diagnostic 
indicating  that  the  attribute  is  not  supported. 

9.9.1  Mandatory  Group 

Only  the  Kernel  Group  of  attributes  is  required.     A  value  for 
<filenanie>,  <permitted  actions>,  and  <contents  type>  will  always 
be  available. 

A  minimum  range  is  required  for  <filename>  values  as  specified 
in  ISO  8571-2.     No  maximum  length  or  format  restrictions  apply. 
A  system  that  does  not  support  <filename>  values  with  a  sequence 
of  more  than  one  Graphic  String  or  extended  <filename> 
characteristics  may  reject  a  request  involving  such  a 
<filename>.     All  systems  must  be  able  to  interpret  a  <filename> 
value  with  a  sequence  of  one  Graphic  String, 

A  Responder  shall  not  require  an  Initiator  to  use  multiple 
component  Graphic  String  filenames.     Requests  using  a  single 
component  <filename>  value  with  a  sequence  of  one  Graphic  String 
shall  be  responded  to  using  a  single  component  <filename>  value. 
Responses  to  requests  involving  <filename>  values  having  two  or 
more  Graphic  Strings  are  not  defined  here  but  may  be  interpreted 
via  bilateral  or  other  external  agreements.     Use  of  <filename> 
values  with  a  sequence  of  more  than  one  Graphic  String  is 
discouraged. 

Apart  from  the  minimum  conformance  requirements  specified  in  ISO 
8571-2,   file  names  have  to  be  specified  in  the  naming  convention 
of  the  responding  FTAM  implementation.     It  is  a  local 
implementation  matter  of  the  FTAM  Responder,  whether  or  not  an 
additional  name  mapping  onto  the  real  Filestore's  file  name 
convention  is  supported. 

In  order  to  enable  interworking  with  all  FTAM  Responders' 
virtual  Filestores,   it  is  recommended  that  FTAM  Initiators 
impose  no  restrictions  on  the  attribute  range  supported  for  file 
names  beyond  those  specified  in  ISO  8571-2. 

For  the  purpose  of  interworking  according  to  these  Agreements  the 
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<contents  type>  attribute  is  limited  to  the  <docuinent  type  name> 
format.     The  <constraint  set  name,  abstract  syntax  name>  form  is 
outside  the  scope  of  these  Agreements.     It  should  always  be 
parsed  correctly  when  received,  but  may  result  in  an  error. 

9.9.2  Optional  Groups 

If  the  optional  Security  Group  of  file  attributes  is 
implemented,  an  actual  value  must  be  available  for  the  <access 
control>  attribute. 

The  <access  control>  attribute  is  a  SET  OF  <access  control 
element>.     The  minimum  requirement  in  these  Agreements  is  the 
support  of  one  <access  control  element>,  according  to  the  base 
standard.     The  terms  <concurrency  access>,  <identity>,  and 
<passwords>  are  each  optionally  supported.     Details  of  their  use 
shall  be  specified  in  the  PICS.     Use  of  the  <location>  term  is 
not  specified  in  these  Agreements. 

Implementation  of  the  Private  Group  is  not  specified. 

9.10  DOCUMENT  TYPE  AGREEMENTS 

These  document  types  are  defined. 

FTAM-1  "ISO  FTAM  unstructured  text" 

FTAM-2  "ISO  FTAM  sequential  text" 

FTAM-3  "ISO  FTAM  unstructured  binary" 

NBS-6  "NBS-6  FTAM  sequential  file" 

NBS-7  "NBS-7  FTAM  random  access  file" 

NBS-8  "NBS-8  FTAM  indexed  file" 

NBS-9  "NBS-9  FTAM  file  directory  file" 

Detailed  document  type  definitions  are  given  in  Appendix  A  and  in  ISO 
8571-2,  Annex  B. 

Note:  Document  types  NBS-1  to  NBS-5  are  not  defined  in  these 

Agreements.  The  numbering  starts  with  NBS-6  because  of  the 
original  DIS  version  of  these  Agreements. 

An  implementation  claiming  conformance  to  these  Agreements  which  also 
supports  any  or  all  of  the  document  types  FTAM-1,  FTAM-2,  and  FTAM-3 
as  defined  in  ISO  8571-2,  Annex  B,  must  minimally  support  the 
combinations  of  parameter  values  as  specified  in  table  9.1. 
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Table  9.1.     Parameters  for  FTAM-1,   -2,  -3 


Universal 

1    Q  G   Ni  1  m)^  p  f 

Maximum 

String 

Si  trni  fi  pance 

FTAM- 

1 

General  String  ^(27) 
IA5String  2(22) 

134  or  less 

'not-signif icant' ^ 

FTAM- 

2 

Graphic  String  ^'^(25) 

134  or  less^ 

'not-significant'^ 

FTAM- 

3 

<not  applicable> 

512  or  less 

'not-significant^ 

Notes:  1.  The  minimum  level  of  support  for  General  String  is  the  ISO 
646,  IRV  GO  character  set  and  the  8859-1  GO  and  Gl 
character  sets,  and  ISO  646,  IRV  CO  set. 


2.  The    support    for    IA5    String    is     the    ISO    646,     IRV  GO 
character  set  and  the  ISO  646,  IRV  CO  set. 

3.  The  minimum  level  of  support  for  Graphic  String  is  the  ISO 
646,  IRV  GO  character  set  and  the  8859-1  GO  and  Gl  sets, 

4.  This  is  the  default  when  the  parameter  is  not  specified. 

5.  The  implementation  need  not  support  Data  Units  whose  total 
character  count  exceeds  134. 


6.  As  per  table  9.3. 

7.  The  length  refers  to  the  number  of  characters  from  the 
applicable  character  set.     It  does  not  include  any  escape 
sequences  or  overhead  from  the  encoding. 

8.  If  escape  sequences  are  used  in  the  encoding  of  the  data 
and  string  boundaries  are  not  maintained  when  the  file  is 
stored,   it  may  be  necessary  for  the  escape  sequences  to 
occur  at  different  locations  when  the  file  is  re-sent. 


For  document  types  which  use  the  sequential  flat  constraint  set, 
conformant  implementations  must  minimally  support  FADU  identities  as 
follows : 


o        for  Transfer  service  class:     'begin',  'end' 

o        for  Transfer  and  Management  service  class:     'begin',  'end' 

o        for  Access  service  class:     'begin',   'end',   'first',  'next' 
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For  the  document  types  NBS-7  and  NBS-8  used  in  conjunction  with  the 
Transfer  service  class  or  the  Transfer  and  Management  service  class,  the 
support  of  the  FADU  identities  of  'current',   'next'  and  'previous'  and  for 
NBS-8  the  support  of  the  FADU  identity  of  'end'  are    outside  the  scope  of 
these  Agreements. 
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For  the  document  types  NBS-6,  NBS-7  and  NBS-8  parameters  are  used  for 
which  the  Agreements  apply  as  specified  in  table  9,2. 


Table  9 

.2.     Parameters  for  NBS- 

6,  NBS-7,  NBS-8 

Parameter 

PrimType 

String- length 

Length- 1 

Length- 2 

int 

INTEGER 

Number  of  octets 
required  to  represent, 
in  2's  complement 
format,  the  largest 
integer  to  be  passed 

bit 

BIT  STRING 

Number  of  bits  in 
string 

(non- varying) 

ia5 

lASString 

Max  number  of 
characters  in  string 

graphic 

Graphic 
String 

Max  number  of 
characters  in  string 

general 

General 
String 

Max  number  of 
characters  in  string 

octet 

OCTET  STRING 

Max  niambers  of  octets 
in  string 

private - 
class-number 

Floating 

Point 

Number 

The  minimum 
number  of  bits 
required  to  be 
maintained  in 
the  mantissa  for 
relative 
precision 

Number  of 
bits  required 
to  represent 
the  largest 
unbiased 
integer  ex- 
ponent in  2's 
complement 

univer- 
time 

UTCTime 

<not  applicable> 

gen- time 

Generalized 
Time 

<not  applicable> 

boolean 

BOOLEAN 

<not  applicable> 

null 

NULL 

<not  applicable> 
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Note:  The  string   length  parameter  specifies  the  actual  number  of 

from  the  referenced  character  set.  It  does  not  include  any 
escape  sequences  or  overhead  from  the  encoding. 

The  primitive  data  types  and  minimal  size  ranges  that  an  implementation 
must  accept  for  storage  are  given  in  table  9.3. 


Table  9.3.     FTAM  primitive  data  types 


Primitive  Data  Tvtie 

Minimum  Range  (Octets) 

ASN.  1 

INTEGER 

1  -  2 

ASN.  1 

BIT  STRING 

0  -  1 

ASN.  1 

lASString 

0  -  134 

ASN.  1 

GeneralString 

0  -  134 

ASN.  1 

GraphicString 

0  -  134 

ASN.l 

OCTET  STRING 

0  -  512 

ASN.  1 

BOOLEAN 

ASN.  1 

NULL 

ASN.  1 

General izedTime 

ASN.  1 

UniversalTime 

NBS-ASl 

Float ingPointNumber 

mantissa 

1-23  bits 

exponent 

0-8  bits 

Notes:  1.  The  primitive  data  types  and  their  maximum  ranges  for 
a  specific  file  as  described  by  the  parameters  above 
are  maintained  in  the  <contents  type>  file  attribute. 
The  <contents  type>  file  attribute  value  is 
established  at  the  file's  creation  and  cannot  be 
changed  via  FTAM  for  the  life  of  the  file.  This 
implies  that  the  data  element  types  and  ranges  and 
data  unit  formats  are  fixed  for  all  accessors  of  that 
file  as  long  as  the  file  exists. 

2.  The  syntax  for  floating  point  numbers  is  part  of  the 
definition  of  NBS  abstract  syntax  ASl  in  Appendix  C.3 
Annex -9A -Part -3 .  It  is  derived  from  existing  standards 
lEC  559  and  IEEE  754. 


9 . 10. 1        Character  Sets 

Implementation  of  a  character  set  in  FTAM  is  understood  as: 

o        a  transfer  syntax  is  defined  for  the  character  set 

o        document  types  are  defined  using  the  character  set  in 
their  abstract  syntactic  definition 
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o        documents  of  those  types  are  stored  in  the  Virtual  File 
Store  as  defined  in  the  character  set  specification. 
They  are  written  into  the  VFS  and  read  from  the  VFS  as 
defined  by  the  abstract  syntax  and  the  transfer  syntax 
for  the  document  type.     It  is  not  in  the  scope  of  FTAM 
Agreements  to  specify  the  local  representation  of  those 
documents  in  the  Real  Filestore,  nor  to  specify 
rendition  of  graphic  characters  or  control  characters 
on  character  imaging  devices.     These  renditions  are 
possible  agreements  between  applications  using  FTAM  for 
their  communication. 

The  character  sets  ISO  646,  IRV  and  ISO  8859-1  shall  always  be 
implemented. 


9. 10. 1 . 1     ISO  646  Character  Set 

The  International  Reference  Version  (IRV)  of  ISO  646  is 
available  for  use  when  there  is  no  requirement  to  use  a 
national  or  an  application-oriented  version.     In  information 
interchange,  the  IRV  is  assumed  unless  a  particular 
agreement  exists  between  sender  and  receiver  of  the  data. 
The  graphic  characters  allocated  to  the  IRV  are  as  specified 
in  table  9.4. 
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Table 

9.4.   IRV  Graphic  Character 

Allocations 

Graphic 

Name 

Coded  Representation 

# 

Number  sign 

2/3 

o 

Currency  sign 

2/4 

(a 

Commercial  at 

4/0 

[ 

Left  square  bracket 

5/11 

\ 

Reverse  solidus 

5/12 

] 

Right  square  bracket 

5/13 

A 

Circumflex  accent 

5/14 

f 

Grave  accent 

6/0 

{ 

Left  curly  bracket 

7/11 

1 

Vertical  line 

7/12 

) 

Right  curly  bracket 

7/13 

Tilde,  overline 

7/14 

It  should  be  noted  that  no  substitution  is  allowed  when  using  the  IRV 
and  that  the  facility  of  combined  vertical  and  horizontal  movements  of 
the  active  position  does  not  apply  to  any  format  effectors. 

It  is  permitted  to  use  composite  graphic  characters  and  there  is  no 
limit  to  their  number.     Because  of  this  freedom,  their  processing  and 
imaging  may  cause  difficulties  at  the  receiving  end.  Therefore 
agreement  between  sender  and  receiver  of  the  data  is  recommended  if 
composite  characters  are  used. 

Note:  Attention  is  drawn  to  the  fact  that  different  national 

character  sets  exist. 

(See  ISO  646  or  CCITT  Recommendation  T.50  for  more  information) 
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9.10.1.2     Format  Effectors 

When  a  single  format  effector  for  vertical  (or  horizontal) 
movement  is  optionally  permitted  to  effect  a  combined 
vertical  and  horizontal  movement,   implementations  shall  not 
use  the  single  format  effector  for  effecting  the  combined 
vertical  and  horizontal  movement. 


Notes:         1.       For       further       information       see  ISO 

646:1983,    clauses    4.1.22    and    6.4,  ISO 

6429:1988,  clause  E.1.2  and  ISO 
4873:1986,  clause  A. 3. 2. 

2.  The  Agreements  require  only  support  of 
CO  control  characters  of  ISO  646, 
containing  among  others  the  format 
effectors     <CR>     and     <LF>.  It  is 

recommended  that  NIST  implementations 
use  <CR>  <LF>  pairs  as  line 
terminators . 


9. 10. 1 .3     8859-1  Character  Set 

The  Latin  Alphabet  No.l  (ISO  8859-1)  is  used  to  specify  the 
printable  characters  of  GO  and  Gl .     CO  control  characters 
and  their  associated  rules  are  taken  from  the  ISO  646 
definition. 


9.10.2        Document  Type  Negotiation  Rules 
9.10.2.1     Connection  Establishment 

In  connection  establishment  the  <contents  type  list> 
parameter  is  used  only  to  establish  presentation  contexts. 
Both  the  <document  type  name>  form  and  the  <abstract  syntax 
name>  form  are  supported  for  responders;   they  are 
optionally  supported  for  initiators. 

9 ■ 10. 2 . 2     File  Creation 

An  <F-CREATE  request>  FPDU  must  contain  a  <document  type 
name>  value  in  its  <initial  attributes>  parameter. 

If  the  specified  document  type  requires  parameterization, 
then  these  parameters  must  be  supplied,  otherwise  the  <F- 
CREATE  request>  may  be  rejected. 
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Notes:  1.  It  is  understood  that  <permitted  actions> 
sub-field  of  <lnitial  attributes>  parameter 
will  always  be  used  at  <F-CREATE  request>. 
The  value  may  be  changed  by  the  Responder. 

2.  If  the  <document  type  name>  used  requires  DU 
syntax  parameters  and  one  of  the  parameters 
specifies  ' FloatingPointNumber '  as  a 
primitive  data  type,  the  request  may  be 
rejected,  in  case  the  optional  type 
'FloatingPointNumber'  is  not  supported  by  the 
Responder . 


9. 10.2.3     File  Opening 

The  <document  type  name>  form  (with  appropriate  parameters 
as  specified  in  8871-2,  Clause  12.3)  shall  always  be  used 
when  proposing  a  <contents  type>;  as  an  alternative  the 
' ContentsTypeUnknown'  value  may  be  used  in  the  <F-OPEN 
request>.     An  <F-OPEN  response>  shall  use  the  <document  type 
name>  option  (with  appropriate  parameters)   in  the  <contents 
type>  field. 

This  allows  the  receiving  entity  to  use  the  <document  type 
name>  attributed  to  the  file  instead  of  receiving  a 
<constraint  set  name>  and  <abstract  syntax  name>  pair,  which 
does  not  reflect  the  file  information  contained  in  the  FTAM 
and  NBS  document  types . 

This  document  type  name  is  either  a  value  from  the  set  of 
base  document  type  names  as  negotiated  upon  connection 
establishment  or  a  document  type  name,   for  which  an 
appropriate  presentation  context  was  established. 

Notes:  1.  An  <F-OPEN  response>  without  a  <document  type 
name>  (but  carrying  the  <constraint  set  name> 
and  <abstract  syntax  name>  form)  may  cause 
the  Initiator  to  issue  an  <F-CLOSE  request>. 

2.  If  the  <document  type  name>  used  requires  DU 
syntax  parameters  and  one  of  the  parameters 
specifies  'FloatingPointNumber'  as  a 
primitive  data  type,  the  request  may  be 
rejected,  in  case  the  optional  type 
'FloatingPointNumber'  is  not  supported  by  the 
Responder . 


9-16 


December  '89 


9.10.3        Relationship  Between  DUs .   DEs  and  Document  Types 

"Abstract  Syntax"  is  used  to  refer  to  the  syntactic  information 
which  is  architecturally  passed  between  the  Application  and 
Presentation  Layers.     The  Abstract  Syntax  defines  Data  Element 
(DE)  types  which  are  not  necessarily  ASN.l  primitive  types.  A 
Data  Element  (DE)   is  the  smallest  piece  of  data  whose  identity  is 
necessarily  preserved  by  the  Presentation  Service.     Data  types 
may  be  made  up  of  other  data  types.     Data  Elements  are  not 
defined  in  terms  of  other  Data  Elements. 

A  Data  Unit  (DU)   is  a  sequence  of  one  or  more  Data  Elements. 
Architecturally,  entire,   single  DEs  are  passed  into  and  out  of 
the  application  process.     In  a  real  implementation,  DUs  may  be 
passed . 

To  maintain  DU  boundaries  during  transfer,   file  structuring 
information  must  be  passed  (IS08571-FADU  definition  in  ISO  8571- 
2,  Clause  7.5).     A  Data  Element  is  referred  to  as  a  File- 
Contents-  Data-Element  in  the  IS08571-FADU  definition. 

Document  types  refer  to  aspects  of  local  processing  and  storage. 
They  describe: 

o        structural  relationship  between  DUs , 

o        structure  of  DUs,   called  DU  syntax,  and 

o        DE  types  found  in  the  file. 

Because  document  types  pertain  to  local  processing  and  storage, 
the  DU  syntax  makes  assertions  about  the  syntax  and  the  size  of 
DUs   (records)   in  storage.     Parameters  on  the  document  types 
provide  this  information  about  the  syntax  and  size  of  the  DUs. 


9.11  F- CANCEL  ACTION 

When  an  F-CANCEL  is  sent  or  received,   the  following  occurs: 

o        no  more  data  is  sent, 

o        checkpoint  numbers  are  removed,  and 

o        state  of  the  file  is  implementation  dependent. 

Note:  When   mapping    F-CANCEL   on    P-RESYNCHRONIZE    (abandon)    it  is 

required  that  P-SYNC-MINOR  be  used  after  F-READ/F-WRITE  (see 
ISO  8571-4  Clauses  13,  14). 
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9.12  IMPLEMENTATION  INFORMATION  AGREEMENTS 

o        The  <implementation  information>  parameter  of  <F-INITIALIZE> 
FPDU  is  not  required  by  these  Agreements. 

o        It  may  be  used  to  pass  user  version  information  as  a  series  of 
values ,  separated  by  ' ; ' . 

o        The  following  will  indicate  conformance  to  the    NIST  Phase  2 
Agreements :     NBS - Phase2 . 

Note:  The  list  of  possible  values  may  be  enlarged  for  future 

FTAM  phases  or  FTAM  profiles  of  other  bodies. 

o        This  parameter  is  for  information  only;   it  is  not  used  for 
negotiation . 

The  establishment  of  an  FTAM  regime  should  not  be  rejected  only 
because  of  an  unknown  <implementation  information>  value. 

9. 13  DIAGNOSTIC  AGREEMENTS 

o        The  <diagnostic>  parameter  is  supported;  a  value  in  the 

<response>  PDU  is  needed  when  the  <action  result>  or  <state 
result>  is  not  zero.     (The  nature  of  these  agreements  is  to 
provide  <diagnostic>  information  when  any  result  parameter  is  not 
' success ' . ) 

o        General  catch-all  diagnostic  action  is  discouraged. 

o        The  <further  details>  subfield  is  supported.     It  will  be  encoded 
as  Graphics tring,  but  is  restricted  to  ISO  646  (IRV,  graphic 
characters)  and  ISO  8859-1  only. 

o        Use  of  F-P-ABORT  for  other  than  protocol  errors  and  catastrophic 
situations  is  discouraged. 

o        When  returning  an  error  status  in  a  file  management  related 
diagnostic  (i.e.,,  <F- READ -ATTRIBUTE  response>  or  <F- 
CHANGE-ATTRIBUTE  response>) ,   identify  the  erroneous  attribute  by 
using  the  first  two  characters  of  <further  details>  to  hold  a 
2-digit  number  (encoded  as  lASString)  from  the  <F-READ-ATTRIBUTE 
request>  attributes  abstract  syntax  definition  (ISO  8571-4, 
Clause  20.3) . 
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00 

Filename 

01 

Permitted  Actions 

02 

Contents  Type 

03 

Storage  Account 

04 

Date  and  Time  of  Creation 

05 

Date  and  Time  of  Last  Modification 

06 

Date  and  Time  of  Last  Read  Access 

07 

Date  and  Time  of  Last  Attribute  Modification 

08 

Identity  of  Creator 

09 

Identity  of  Last  Modifier 

10 

Identity  of  Last  Reader 

11 

Identity  of  Last  Attribute  Modifier 

12 

File  Availability 

13 

File  Size 

14 

Future  Filesize 

15 

Access  Control 

16 

Legal  Qualifications 

17 

Private  Use 

The  set  of  file  management  diagnostics,  found  in  ISO  8571-3  Annex 
A,  must  be  supported. 

In  the  case  where  a  specific  parameter  can  in  no  way  be 
accommodated  then  the  request  fails  and  a  <diagnostic>  indicating 
one  such  parameter  should  be  returned  by  the  responder.     In  the 
case  where  a  negotiable  parameter  cannot  be  accommodated  with 
exactly  the  value  requested  but  is  negotiated  to  a  different 
value  (as  defined  in  the  standard)  then  the  request  formally 
succeeds  but  informative  <diagnostics>  indicating  those 
parameters  negotiated  should  be  returned. 

In  order  to  provide  for  robust  applications  using  FTAM,  well 
defined  and  precise  diagnostics  are  required  to  be  returned  by 
responding  implementations  whenever  an  action  cannot  be  carried 
out  precisely  as  requested  with  respect  to  non-negotiable 
parameters.     All  such  applicable  diagnostics  will  be  returned  in 
those  cases.     An  action  is  carried  out  precisely  as  requested 
with    respect  to  a  parameter  when  the  value  of  that  parameter  on 
the  <request>  FPDU  is  equal  to  the  value  in  effect  during  or 
subsequent  to  the  action,  depending  on  whether  the  action  is 
regime  control. 

Diagnostics  exist  to  signal  'parameter  not  supported'  and 
Responder  implementations  shall  issue  all  appropriate 
diagnostics.     The  <further  details>  subfield  of  the  <diagnostic> 
parameter  shall  specify  the  parameter  which  is  not  implemented. 
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9.14  CONCURRENCY 

The  <concurrency  control>  used  by  default  on  actions  requested  by  an 
<F-SELECT  indication>  or  <F-CREATE  indication>  service  are: 

'shared'  for  read  and  read  attribute 

'exclusive'         for  all  other  actions 

The  default  for  actions  not  requested  is  specified  as   'not  required' 
as  per  ISO  8571-3. 

Note:  A  local  implementation  may  choose  to  be  more  restrictive  in 

order  to  assure  file  consistency  for  concurrent  accessors. 

FADU  locking  is  not  required. 

9.15  REQUESTED  ACCESS 

The  <requested  access>  parameter  on  <F-SELECT>  or  <F-CREATE>  is  used 
to  specify  the  actions  which  the  Initiator  may  perform  during  the  file 
selection.     The  value  of  the  <requested  access>  parameter  is  compared 
by  the  Responder  to  the  <access  control>  and  <permitted  actions>  file 
attributes  and  concurrency  controls  (including  those  requested  by  the 
Initiator)  currently  in  place  on  the  file.     If  the  value  of  the 
<requested  access>  parameter  is  not  consistent  with  either  <access 
control>,  <permitted  actions>,  or  concurrency  controls  in  place,  then 
the  <F-SELECT>  or  <F-CREATE>  must  be  rejected. 

<requested  access>  is  consistent  with  <access  control>  if,  for  each 
action  requested,  that  action  either  requires  no  password,  or  the 
required  password  has  been  specified  on  the  <F- SELECT  request>  or  <F- 
CREATE  request>. 

<requested  access>  is  consistent  with  <permitted  actions>  if,   for  each 
action  requested,   that  action  is  allowed  by  the  <permitted  actions> 
file  attribute. 

<requested  access>  is  consistent  with  <concurrency  control>  requested 
on  the  <F-SELECT>  or  <F-CREATE>  if,  for  each  action  requested,  that 
action  has  not  been  specified  as   'not  required'   or  'no  access'   in  the 
<concurrency  control>  parameter. 

<requested  access>  is  consistent  with  concurrency  controls  in  place  on 
the  file  if  for  each  action  requested  no  other  accessor  of  the  file 
has  set  the  concurrency  control  for  that  action  to  either  'exclusive' 
or  ' no  access ' . 
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9. 16  SECURITY 

9.16.1  Initiator  Identity  and  Filestore  Password 

The  <initiator  identity>  and  <filestore  password>  parameters  for 
an  implementation  acting  as  an  Initiator  are  supported.  These 
parameters  are  optional  for  an  implementation  acting  as  a 
Responder. 

The  syntax  of  <initiator  identity>  and  <filestore  password>  is 
system-dependent.     <initiator  identity>  and  <filestore  password> 
will  represent  account  information  on  the  local  system,  which 
may  be  different  from  the  <account>  parameter. 

9.16.2  Access  Passwords 

The  <access  passwords>  and  <create  password>  parameters  for  an 
implementation  acting  as  an  Initiator  are  supported  if  the 
Security  Group  of  attributes  is  supported.     These  parameters  for 
an  implementation  acting  as  a  Responder  are  optionally  supported 
if  the  Security  Group  is  supported. 

9.16.3  Implementation  Responsibilities 

It  is  the  responsibility  of  each  local  system  to  provide  security 
for  its  own  real  filestore.     Encryption  of  passwords  will  not  be 
done  by  FTAM. 

A  user  of  the  file  service  must  be  known  by  the  Responder. 
"Known"  is  defined  by  the  local  Filestore,  and  is  dependent  on 
the  level  of  security  provided  by  the  local  Filestore. 

9.17  REQUIREMENT  FOR  CONFORMANT  IMPLEMENTATIONS 

This  section  gives  the  criteria  to  be  satisfied  by  every 
implementation  of  FTAM  that  conforms  to  these  Agreements. 

Conformance  to  these  Agreements  is  stated  in  terms  of  the  different 
roles  occupied  by  FTAM  implementations.     The  interoperability  of 
certain  configurations  of  these  roles  motivates  this  approach. 
Interoperable  configurations  of  these  roles  are  given  in  section 
9.17.1. 

The  only  function  provided  by  every  conformant  implementation  is  the 
transfer  of  unstructured  binary  files  in  their  entirety.     It  must  be 
recognized  that  such  simple  transfer,  while  commonly  understood  and 
generally  important,  will  not  support  all  applications  of  FTAM. 
section  9.18  defines  Implementation  Profiles  of  FTAM  services  and 
protocol  that  can  provide  other  specific  functions.     Those  other 
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functions  exploit  the  access  and  management  capabilities  of  FTAM.  The 
unconstrained  service  class  (with  appropriately  chosen  functional 
units)  can  be  used  to  provide  the  functions  of  any  of  the 
Implementation  Profiles.     Users  of  FTAM  must  consider  carefully  what 
functions  they  require.     They  must  examine  all  the  Implementation 
Profiles  and  select  according  to  their  needs. 

Implementation  conforming  to  these  Agreements  require  adherence  to 
the  General  Agreements  in  sees.  9.5  through  9.16  of  these  Agreements. 


9.17.1         Interoperable  Configurations 

Any  implementation  conforming  to  this  specification  must  be  able 
to  act  in  at  least  one  of  the  following  role  combinations: 

1.  initiator  and  receiver, 

2.  initiator  and  sender, 

3.  responder  and  sender, 

4.  responder  and  receiver. 

Minimal  implementations  of  combination  1  will  interoperate  with 
minimal  implementations  of  combination  3.  Minimal 
implementations  of  combination  2  will  interoperate  with  minimal 
implementations  of  combination  4. 

Any  implementations  of  roles  1  and  3  will  be  able  to  interoperate 
at  the  intersection  of  their  capabilities  (which  will  be  at  least 
the  minimal  capabilities  described  in  sees.  9.17.3  to  9.17.8). 
Any  implementations  of  roles  2  and  4  will  be  able  to  interoperate 
at  the  intersection  of  their  capabilities  (which  will  be  at  least 
the  minimal  capabilities  described  in  sects.  9.17.3  to  9.17.8). 

These  role  combinations  and  this  interoperability  are  shown  in 
table  9.5  below. 
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Table  9.5.     Interoperable  configurations 


Initiator 

Responder 

sender 

receiver 

sender 

receiver 

Initiator 

sender 

X 

receiver 

X 

Responder 

sender 

X 

receiver 

X 

9.17.2  Relationship  to  ISO  8571 --The  FTAM  Standard 

Any  implementation  in  conformance  to  ISO  8571   (as  defined  in  ISO 
8571-4,  Clause  22  (Conformance)),   in  addition  to  the 
implementation  of  the  minimal  protocols  and  roles  enumerated  in 
sections  9.17.3  to  9.17.8,   is  considered  to  be  in  conformance 
with  these  Agreements.     Any  implementation  violating  any  of  the 
conformance  statements  in  ISO  8571-4  is  considered  to  be  in 
violation  of  these  Agreements. 

9.17.3  Requirements  for  Document  Type  Support 

The  document  type  FTAM- 3  shall  be  supported  for  purposes  of 
transfer  and  storage.     The  details  regarding  support  for  FTAM- 3 
in  the  FTAM  dialogue  are  given  in  section  9.10. 

Support  of  document  types  other  than  FTAM- 3  is  not  required  for 
conformant  implementations.     Support  for  document  types  described 
in  these  Agreements  also  entails  support  for: 

o        the  semantics  given  in  their  description  and  further 
qualified  in  9.10 

o        the  preferred  transfer  syntax  "Basic  Encoding  of  a 
single  ASN.l  type" 

9.17.4  Initiators 

Every  implementation  of  an  FTAM  Initiator  shall  support: 

o        the  kernel  protocol  and  its  mandatory  parameters  with 
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minimum  ranges   [Minimum  required  ranges  are  specified 
in  sec.  9.17.8.  ]  , 

o        the  grouping  protocol  and  the  <threshold>  parameter 
with  a  value  of  at  least  2  for  use  in  the  file 
transfer  class, 

o        at  least  one  of  the  read  or  write  protocols  [Specific 
conformance  for  reading  and  writing  is  defined  in 
sees.  9.17.6  and  9.17.7. ] , 

and  support  the  applicable  procedures  defined  in  ISO  8571-4 
clauses  8.1   (FTAM  regime  establishment),   8.2  (FTAM  regime 
termination),   8.3   (File  selection),   8.4  (File  deselection),  8.9 
(File  open),   8.10  (File  close),   8.11   (Begin  group),   8.12  (End 
group) ,   and  10  (File  general  actions) .     To  support  the  above 
protocols  and  procedures  the  implementation  shall  always  support 
the  kernel  functional  unit  and  additionally  shall  be  able  to: 

o        request  the  grouping  and  at  least  one  of  the  read  or 
write  functional  units, 

o        request  the  file  transfer  class  with  the  <service 
class>  parameter, 

o        request  the  document  type  FTAM-3  using  the  <document 
type  name>  form  of  the  <contents  type>  parameter, 

o        request  the  <FTAM  quality  of  service>  parameter  with 
value  0  and  accept  in  all  cases  the  returned  value  0, 
and 

o        request  a  <communication  quality  of  service>  consistent 
with  the  transport  definition  in  these  Agreements 

as  part  of  the  Filestore  initialization  procedures  in  ISO  8571- 
4  clause  8.1,   FTAM  regime  establishment. 

Initiators  must  be  able  to  operate  under  all  circumstances  if 
the  above  minimum  values  are  successfully  negotiated  and 
returned  on  an  <F- INITIALIZE  response>  FDU.     Initiators  must  be 
able  to  operate  with  any  downward  negotiation  of  requested 
parameter  values  as  described  in  the  standard. 

Should  the  supporting  services  break  down,   such  that  FTAM 
communication  is  impossible,   the  FTAM  protocol  machine  shall 
notify  the  user  with  an  <F-P-ABORT  indication>  and  <diagnostic> 
value  with  identifier  1011,   as  well  as  any  known  <further 
details> . 

Note:  Interworking  may  not  be  possible  between  Initiators  not 

supporting  attributes  of  the  Storage  Group  and  Security 


9-24 


December  '89 


Group,  and  Responders  requiring  these  attributes  to  be 
used. 


9.17.5  Responders 

Every  implementation  of  an  FTAM  Responder  shall  support: 

o  the  kernel  protocol  and  its  mandatory  parameters  with 
minimum  ranges  [Minimum  required  ranges  are  specified 
in  sec.   9.17.8.  ]  , 

o        the  grouping  protocol  and  the  <threshold>  parameter 
with  a  value  of  at  least  2  for  use  in  the  file 
transfer  class, 

o        at  least  one  of  the  read  or  write  protocols  [Specific 
conformance  for  reading  and  writing  is  defined  in 
sections  9.17.6  and  9.17.7], 

and  support  the  applicable  procedures,   defined  in  ISO  8571-4 
clauses  9.1   (FTAM  regime  establishment),   9.2   (FTAM  regime 
termination),   9.3  (File  selection),   9.4  (File  deselection),  9.9 
(File  open),   9.10  (File  close),   9.11   (Begin  group),   9.12  (End 
group) ,   and  10  (File  general  actions) .     To  support  the  above 
protocols  and  procedures  the  implementation  shall  always  support 
the  kernel  functional  unit  and  additionally  shall  be  able  to: 

o        accept  requests  for  the  grouping  and  at  least  one  of 
the  read  or  write  functional  units, 

o        accept  requests  for  the  file  transfer  class  with  the 
<service  class>  parameter, 

o        accept  the  document  type  FTAM- 3  using  the  <document 
type  name>  form  of  the  <contents  type>  parameter, 

o        accept  requests  for  an  <FTAM  quality  of  service> 
parameter  with  any  value  but  may  respond  with  the 
value  0 ,  and 

o        accept  requests  for  a  <communication  quality  of 

service>  consistent  with  the  transport  definition  in 
these  agreements 

as  part  of  the  filestore  initialization  procedures  in  ISO  8571- 
4  clause  9.1,   FTAM  regime  establishment. 

Responders  must  be  able  to  operate  under  all  circumstances  if 
the  above  minimum  values  are  requested  on  an  <F- INITIALIZE 
request>  PDU.  Responders  must  not  negotiate  upward  in  the  sense 
described  in  the  standard. 
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Responders  must  complete  each  action  requested  and  supported  in  a 
manner  consistent  with  its  description  in  ISO  8571-2  Clauses  10 
(Actions  on  complete  files)  and  11  (Actions  for  file  access),  and 
must  interpret  each  supported  attribute  in  a  manner  consistent 
with  its  definition  in  ISO  8571-2  Clause  12  (File  attributes). 

Under  circumstances  where  actions  cannot  be  carried  out  either  as 
requested  or  consistently  with  ISO  8571-2  Clause  10  (Actions  on 
complete  files)  and  12  (Actions  for  file  access) ,  the  Responder 
must  return  at  least  one  diagnostic  indicating: 

o        if  the  failure  was  due  to  either  a  protocol  or 
Filestore  failure,  and  then: 

precisely  which  action  failed, 

at  least  one  of  the  parameters  that  could  not  be 
accommodated    with  the  diagnostic  type  indicating 
at  least  the  degree  of  failure,  as  given  by  the 
action  and  state  result  parameter,  or 

o        that  the  failure  was  due  to  unforeseen  system  shutdown. 

Should  the  supporting  services  break  down,   such  that  FTAM 
communication  is  impossible,  the  FTAM  protocol  machine  shall 
notify  the  user  with  an  <F-P-ABORT  indication>  and  <diagnostic> 
with  identifier  1011,  as  well  as  inform  the  user  of  any  known 
<further  details>. 


9.17.6  Senders 

Every  implementation  of  an  FTAM  sender  shall  support  the  read 
functional  unit  as  Responder  or  the  write  functional  unit  as 
Initiator,   and  support  the  applicable  procedures  defined  in  ISO 
8571-4  Clauses  11   (State  of  the  bulk  data  transfer  activity),  12 
(Bulk  data  transfer  protocol  data  units) ,   15  (Bulk  data  transfer 
sending  entity  actions),   17.1   (Discarding),   and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  shall  be  able  to 
send  files  of  the  document  type  FTAM- 3  and  shall  be  able  to  send 
them  as  user  data  in  PPDUs  in  blocks  of  up  to  7168  octets. 

9.17.6.1     Initiator  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  FTAM 
Initiator  shall  support: 

o        the  write  functional  unit  and  protocol,  and 

o        for  the  document  type  FTAM- 3  the  following  bulk 
data  transfer  specification  parameters: 
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FADU  operation  replace 
FADU  identity  first 

and  support  the  applicable  procedures,  defined  in  ISO  8571-4 
Clause  13  (Bulk  data  transfer  initiating  entity  actions) . 

9.17.6.2    Responder  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  FTAM 
Responder  shall  support: 

o        the  read  functional  unit  and  protocol,  and 

o        for  the  document  type  FTAM- 3  the  following  bulk 
data  transfer  specification  parameters: 

FADU  identity  first 
Access  context  UA 

and  support  the  applicable  procedures,  defined  in  ISO  8571-4 
Clause  14  (Bulk  data  transfer  responding  entity  actions) . 

9.17.7  Receivers 

Every  implementation  of  an  FTAM  receiver  shall  support  the  read 
functional  unit  as  Initiator  or  the  write  functional  unit  as 
Responder,  and  support  the  applicable  procedures,  defined  in  ISO 
8571-4  Clauses  11  (State  of  the  bulk  data  transfer  activity),  12 
(Bulk  data  transfer  protocol  data  units),  16  (Bulk    data  transfer 
receiving  entity  actions),   17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  shall  be  able  to 
receive  files  of  the  document  type  FTAM- 3  and  shall  be  able  to 
receive  them  as  user  data  in  PPDUs  in  blocks  of  at  least  7168 
octets . 


9.17.7.1    Initiator  Receivers 

Every  implementation  of  an  FTAM  receiver  which  is  also  an 
FTAM  Initiator  shall  support: 

o        the  read  functional  unit  and  protocol,  and 

o        for  the  document  type  FTAM- 3  the  following  bulk 
data  transfer  specification  parameters: 

FADU  identity  first 
Access  context  UA 
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and  support  the  applicable  procedures,  defined  in  ISO  8571-4 
Clause  13  (Bulk  data  transfer  initiating  entity  actions) . 


9.17.7.2    Responder  Receivers 

Every  implementation  of  an  FTAM  receiver  which  is  also  an 
FTAM  Responder  shall  support: 

o        the  write  functional  unit  and  protocol,  and 

o        for  the  document  type  FTAM- 3  the  following  bulk 
data  transfer  specification  parameters: 

FADU  operation  replace 
FADU  identity  first 

and  support  the  applicable  procedures,  defined  in  ISO  8571-4 
Clause  14  (Bulk  data  transfer  responding  entity  actions) . 


9.17.8        Minimum  Ranges 

Any  implementation  of  any  conformant  FTAM  configuration  shall  be 
able  to  receive  and  meaningfully  process  all  mandatory  parameters 
for  all  functional  units  supported  as  well  as  the  <diagnostic> 
parameter  within  at  least  the  minimum  ranges  of  values  given  in 
table  9.6.     A  conforming  implementation  may  support  a  wider 
range  of  values  for  any  parameter. 
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Table  9.6.     Required  minimal  parameter  support 


Parameter 


Minimuin  Range 


general 


F  INITIALIZE 


diagnostic 


action  result 
state  result 


functional  units ^ 


presentation  context  managements^ 

all  others 


F  SELECT 


attributes 


requested  access 


F- CREATE 


override 


Values  as  specified  in  ISO  8571-3  Annex  A 
(Diagnostic  parameter  values)  tables  44, 
45  and  46  which  correspond  directly  to 
mandatory  parameters. 
All  values. 
All  values. 


'read'   (for  initiator/receivers  and 
responder/senders)  and  'grouping' 
or 

'write'    (for  initiator/senders  and 
responder/receivers)  and  'grouping' 
'False' 

As  specified  in  sections  9.17.4  and 
9.17.5  above. 


Only  <filename>  is  used  with  a  minimum 
supportable  length  of  8  characters.  Any 
other  attribute  supported  for  other 
services  must  have  minimum  supported 
lengths  as  in  ISO  8571-2  Clause  15 
(Minimum  attribute  ranges)  table  2. 

'read'  for  initiator/receivers 
'read'  for  responder/senders 
'replace'   for  initiator/senders 
'replace'  for  responder/receivers 


For  Responders ,  the  values  'create- 
failure',    ' select-old- file '  and 
' delete-and-create-with-new-attributes ' 
are  supported.     The  value  ' delete -and- 
recreate-with-old-attributes '  is 
optionally  supported.     All  values  are 
optional  for  Initiators. 


(Continued  on  next  page.) 
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Table  9.6.     Required  minimal  parameter  support,  continued 


Parameter 

Minimum  Range 

F_ 

OPEN 

processing  mode  ' 

read'   for  initiator/receivers 

'read'   for  responder/senders 

'replace'  for  initiator/senders 

'replace'  for  responder/receivers 

contents  type 

FTAM- i 

F 

READ 

FADU  identity 

' first' 

access  context 

'UA' 

F_ 

WRITE 

FADU  operation 

'read'   for  initiator/receivers 

'read'   for  responder/senders 

'replace'   for  initiator/senders 

'replace'   for  responder/receivers 

FADU  identity 

'first' 

F_ 

_BEGIN_GROUP 

threshold-^ 

For  file  transfer  (a  minimal  required 

function)  2. 

For  any  other  supported  parameters ,  minimum  ranges  are  taken  from 
the  minimum  ranges  for  the  attribute  corresponding  to  each  as  in 
ISO  8571-2  table  4. 

Notes:  1.  The  parameters,  functional  units,  and  presentation  context 
management  are  not  ordered,  so  "minimum  value"  cannot  be 
formally  defined.  The  above  values  are  those  required  for 
conformance  to  these  Agreements  but  no  value  conformant  to 
ISO  8571  for  use  in  other  applications  is  regarded  to  be  in 
violation  of  these  Agreements. 

2.  Other  functional  units  (and  service  classes)  for  defined 
implementations  may  also  be  valid  provided  that  they  are 
implemented  in  accordance  with  these  Agreements, 
specifically  section  9.17.8. 

3.  Every  implementation  must  support  the  <threshold>  value  2  to 
provide  the  basic  required  function  of  file  transfer;  any 
other  value  in  other  applications  is  acceptable. 


9. 17 .9      Range  of  Values  for  INTEGER  Type  Parameters 
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The  general  range  for  parameters  of  type  INTEGER  to  the  FTAM  PCI 
is  as  specified  in  the  UNIVERSAL  ASN.l  ENCODING  RULES  section  of 
the  Upper  Layers  chapter. 

The  parameters 

FTAM  Attributes 
f  ilesize 
future -  files ize 

FADU- Identity 

fadu- number 

may  be  encoded  so  that  the  length  of  its  contents  octets  is  no 
more  than  eight  octets. 

In  the  case  of  receiving  more  than  4  contents  octets ,  the 
receiver  may  reject  the  corresponding  FTAM  PDU. 

Note:  To  guarantee  interworking ,  encoding  should  be 

restricted  to  the  range  -2^-'^  to  2-^-^-1. 

Use  of  Lower  Layer  Services 

Support  for  the  Presentation  Context  Management 
functional  unit  is  not  required. 

Implementations  will  support  the  Session, 
Presentation,  and  ACSE  requirements  as  stated  in 
section  5  of  this  document. 

Implementation  of  the  Session  Resychronize  and  the 
Minor  Synchronize  functional  units  is  highly 
recommended,  since  the  F-CANCEL  service  may  be  less 
effective  when  mapped  to  S-DATA. 

9. 18  IMPLEMENTATION  PROFILES 

This  section  defines  Implementation  Profiles  for  the  specific 
functions  of: 

o        File  Transfer 

o        File  Access 

o        File  Management. 

Those  definitions  are  expressed  in  terms  of: 

o        Document  Types 
o  Attributes 


9.17.10 


Note: 
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o        Service  Classes  (both  service  elements  and  their 
parameters) . 

This  by  no  means  defines  all  possible  Implementation  Profiles. 
The  following  Implementation  Profiles  are  defined: 

Tl:     Simple  File  Transfer 
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T2 
T3 
Al 
A2 
Ml 


Positional  File  Transfer 
Full  File  Transfer 
Simple  File  Access 
Full  File  Access 
Management . 


Implementation  Agreements  have  been  reached  for  the  following  service 
classes.     Note  that  any  given  implementation  may  support  more  than  one 
service  class. 


o  File  Transfer 

o  File  Access 

o  File  Management 

o  Unconstrained 

o  File  Transfer  and  Management 


Support  of  an  Implementation  Profile  requires  adherence  to: 

1.  corresponding  definition  in    8571-3  Clause  8  and  any  related 
procedures  in  8571-4  Clause  8-17, 

2.  requirements  given  in  sections  9.5-9.18  of  these  Agreements,  and 

3.  requirements  for  parameter  and  attribute  support  as  defined  in 
section  9.17.8. 


9.18.1        General  Requirements  for  the  Defined  Implementation 
Profiles 


o        Implementations  will  be  able  to  act  either  as  Initiator  or 
Responder  or  both. 

o        Implementations  must  support  diagnostics  as  described  in 
section  9.13  of  these  Agreements. 

o        Implementations  that  support  the  file  access  service  class 
will  support  access  to  sequential  files.     Support  of 
sequential  files  entails  hierarchy  of  depth  and  arc  length 
equal  to  1 .     Other  hierarchy  depth  and  arc  lengths  are  not 
precluded  by  these  agreements. 

9.18.2  (deleted) 


9.18.3        Document  Type  Requirements  for  the  Defined 
Implementation  Profiles 

Implementations  conformant  to  Implementation  Profiles  defined  in 
table  9.7  will  support  the  following  document  types  with  the 
caveats  and  procedures  given.     Those  document  types  are  defined 
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in  Appendix  9A  and  section  9.10  of  these  Agreements,   and  in  ISO 
8571-2. 

o        FTAM- 1 

o        FTAM- 2 

o        FTAM- 3 

o  NBS-6 

o  NBS-7 

Note:  Support  of  this  document  type  entails  the 

naming  of  FADUs  by     their  position  in 
preorder  traversal. 

Caveat:  Other  methods  of  naming  FADUs  depend  on  the 
system,  application,  and  specific  file,  and 
as  such  are  not  described  here . 

o  NBS-8 
o  NBS-9 

Support  for  any  document  type  requires  the  ability  to  transfer 
and  store  the  abstract  syntax  given  in  its  definition.  These 
Agreements  do  not  specify  techniques  or  formats  for  storage. 

Caveat:       Specific  abstract  syntaxes  for  the  parameterized 

document  types  NBS-6, 7, 8  are  not  specified  in  these 
Agreements . 

Any  document  type  supported  must  be  identifiable  by  its  document 
type  name  as  given  in  ISO  8571-2  and  in  Appendix  9A  of  these 
Agreements  and,  where  defined,   the  parameterization  scheme  given 
in  section  9.10  of  these  Agreements. 

For  conformance  to  NBS-9  a  Responder  is  only  required  to  return 
the  <filename>  attribute,   subject  to  local  security  and  access 
control.     All  other  requested  attributes  need  not  be  returned. 

Systems  supporting  the  NBS-9  document  type  shall  make  available 
an  NBS-9  document  called  'DIRLIS'.     This  document  can  be  used  to 
obtain  a  listing  of  files  and  their  associated  attributes  from  a 
remote  Filestore. 

Creation  and  deletion  of  NBS-9  files  are  outside  the  scope  of 
these  Agreements . 

File  security  issues  related  to  NBS-9  are  subject  to  the  security 
agreements  outlined  in  section  9.16. 
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9.18.4        Parameters  for  the  Defined  Implementation  Profiles 

o        Implementations  will  support  the  <contents  type  list> 

parameter  on  the    <F-INITIALIZE>  service  element.  The 

initiating  service  must  supply  a  value  for  this 
parameter . 


o        Implementations  will  support  the  <diagnostic>  parameter 
as  stated  in  section  9.13  of  these  Agreements. 

o        The  <initiator  identity>  parameter  is  supported.  Use 
must  be  consistent  with  section  9.16  of  these 
Agreements . 

o        Implementations  are  not  precluded  from  using  other 
parameters  for  security  and/or  accounting. 
Respondersmust  state  the  syntax  and  the  semantics 
applying  to  <account>  and  <charging>  parameters.  The 
Responder's  minimum  implementation  is  to  accept  but 
ignore  the  <account>. 


9.18.5        Parameter  Ranges  for  the  Defined  Implementation 
Profiles 

Parameter  ranges  for  Implementations  Profiles  are  as  stated  for 
primitive  data  types  in  section  9.10  of  these  agreements. 


9.18.6        File  Attribute  Support  for  Implementations 

Implementations  of  the  Implementation  Profiles  will  support  file 
attributes  or  attribute  groups  in  the  following  ways. 

o  mandatory 

This  feature  is  mandatory  in  the  ISO  8571-2 
standard  and  shall  therefore  be  implemented  by  all 
implementations  claiming  conformance  to  these 
Agreements . 

o  supported 

This  feature  shall  be  implemented  by  all 
implementations  claiming  conformance  to  these 
Agreements  (for  attributes,   this  implies  that  at 
least  the  minimum  range  of  attribute  values,  as 
defined  in  ISO  8571-2  Clause  15,   shall  be 
supported) .     Conformant  implementations  shall  also 
be  able  to  interwork  with  other  implementations 
that  do  not  support  this  feature  by  negotiating 
out  the  corresponding  features. 

o        optionally  supported 
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Implementations  claiming  conformance  to  these 
Agreements  may  or  may  not  implement  this  feature 
(for  attributes,   this  implies  that  at  least  either 
the  minimum  range  of  attribute  values,  as  defined 
in  ISO  8571-2  Clause  15,   shall  be  supported  or 
that  the  'no  value  available'  result  shall  be 
supplied) .     If  an  attribute  group  with  a  support 
level  of  'optionally  supported'   is  chosen  to  be 
supported,  then  all  the  attributes  of  this  group 
that  are  classified  as  'mandatory'  or  'supported' 
shall  be  supported. 

o        not  supported 

This  feature  is  outside  the  scope  of  these 
Agreements . 


Kernel  Group 


mandatory 


o  Filename 

o  Permitted  Actions 

o  Contents  Type 

Storage  Group 

o  Storage  Account 

o  Date  and  Time  of  Creation 

o  Date  and  Time  of  Last  Modification 

o  Date  and  Time  of  Last  Read  Access 

o  Date  and  Time  of  Last  Attribute  Modification 

o  Identity  of  Creator 

o  Identity  of  Last  Modifier 

o  Identity  of  Last  Reader 

o  Identity  of  Last  Attribute  Modifier 

o  File  Availability 

o  Filesize 

o  Future  Filesize 

Security  Group 

o  Access  Control 

o  Legal  Qualifications 


mandatory 
mandatory 
mandatory 

optionally  supported 


optionally 

optionally 

optionally 

optionally 

optionally 

optionally 

optionally 

optionally 

optionally 

supported 

supported 

optionally 


supported 
supported 
supported 
supported 
supported 
supported 
supported 
supported 
supported 


supported 


optionally  supported 
supported 

optionally  supported 


Private  Group 


not  supported 
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Table  9.7.     Implementation  profile  support  requirements 


Functional  Unit 

T 

Service  Class  (See  Note  8) 
M                 A               T&M  UNCST 

Kernel 

Read          (See  note  3.) 

Tl ,T2,T3 
T1,T2,T3 

Ml 

Al,A2 
A1,A2 

Write        (See  note  3.) 

Tl ,T2,T3 

Al  ,A2 

Limited  File  Mgmnt . 
Enhanced  File  Mgmnt. 
Grouping 
File  Access 

SeeNote  6 
T1,T2,T3 

Ml 
Ml 
Ml 

SeeNote  6 
Al  ,A2 

See 

See 

Document  Types 

FTAM-1 
FTAM-2 
FTAM-3 

Tl ,T2,T3 
T2,T3 
Tl ,T2,T3 

[Ml] 
[Ml] 
[Ml] 

Al  ,A2 
Al  ,A2 
Al  ,A2 

Note 

Note 

NBS-6 

[T2] ,T3 

[Ml] 

[Al] ,A2 

4 

5 

NBS-7 

[T2] ,T3 

[Ml] 

[Al] ,A2 

NBS-8 

T3 

[Ml] 

A2 

NBS-9 

[Tl] , [T2] 
[T3] 

[Ml] 

Notes:  to  9.18.3  and  table  9.7 

1.  The  Management  Implementation  Profile  is  only  to  be  implemented  in 
conjunction    with  one  of  the  Transfer  or  Access  Profiles. 

2.  Profile   T2    is   subset  of  T3 .      Al   and  Tl   are  subsets   of  A2   and  T2, 
respectively. 

3.  Profiles  Tl ,  T2,  and  T3  require  the  support  of  read  and/or  write 
functional  units . 

4.  Support  of  the  <File  Transfer  and  Management>  service  class  is 
optional.  The  rules  for  including  it  in  a  request  and  for  the 
response  to  it  are  as  given  in  ISO  8571-3,  Clause  10.1.  Any 
implementation  including  TM  in  the  request  must  be  prepared  for  the 
possibility  that  it  might  be  removed  from  the  response. 
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5.  The  support  of  the  <Unconstrained>  service  class  is  outside  the  scope 
of  these  Implementation  Profiles. 

6.  Limited  File  Management  is  not  required  for  the  T-  and  A- 
Implementation  Profiles,  but  very  often  it  will  be  a  user  request  to 
have  limited  file  management  functionality  available  together  with 
file  transfer  and  file  access  functions.  So  Limited  File  Management 
may  be  added  as  an  option  to  the  T-  and  A-  Implementation  Profiles. 

7.  []  in  table  9.7  specifies  that  the  document  type  is  optional  for  the 
respective  Implementation  Profile.  For  Ml  the  support  level  depends 
on  the  T-  or  A-  Implementation  Profile,  in  conjunction  with  which  Ml 
is  implemented. 

8.  The  Implementation  Profiles  specify  functionality  which  includes  the 
requirements  for  conformant  implementations  as  specified  in  section 
9.17.  This  is  a  general  basic  requirement  and  is  not  also  reflected 
in  table  9.7. 


9 ■ 19  PROVISION  OF  SPECIFIC  FUNCTION 

9.19.1         Implementation  Profile  Tl :     Simple  File  Transfer 

Implementation  Profile  Tl  provides  the  function  of  transferring 
entire  files  at  the  external  file  service  level  for  files  v/ith  an 
unstructured  constraint  set.     This  includes  support  of  the 
document  types : 

o        FTAM-1        "ISO  FTAM  unstructured  text" 

o        FTAM-3        "ISO  FTAi4  unstructured  binary" 

o        NBS-9  "NBS-9  file  directory  file"  (optional) 

This  Implementation  Profile  supports  file  transfer  and  not  file 
access,   that  is,   the  ability  to: 

o        read  a  complete  file 

and/or 

o        write  (replace,  extend)  to  a  file. 


9 . 19 .2        Implementation  Profile  T2 :     Positional  File  Transfer 

Implementation  Profile  T2  provides  the  function  of  transferring 
files  at  the  external  file  service  level  for  files  with  an 
unstructured  or  fiat  constraint  set.     This  includes  support  of 
the  document  types : 

o        FTAM-1        "ISO  FTAM  unstructured  text" 
o        FTAM- 2        "ISO  FTAM  sequential  text" 
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o  FTAM-3  "ISO  FTAM  unstructured  binary" 

o  NBS-6  "NBS-6  FTAM  sequential  file"  (optional) 

o  NBS-7  "NBS-7  FTAM  random  access  file"  (optional) 

o  NBS-9  "NBS-9  file  directory  file"  (optional) 

This  Implementation  Profile  supports  file  transfer  and  not  file 
access,   that  is,   the  ability  to: 

o        read  a  complete  file  or  a  single  FADU  which  is 
identified  by  position 

and/or 

o        write  (replace,   extend,   insert  depending  on  constraint 
set  and  document  type)  to  a  file  or  an  FADU. 

This  Implementation  Profile  is  upwardly  compatible  to  Tl  for  the 
transfer  of  unstructured  files. 


9.19.3        Implementation  Profile  T3 :     Full  File  Transfer 

Implementation  Profile  T3  provides  the  function  of  transferring 
files  at  the  external  file  service  level  for  files  with  an 
unstructured,   flat  or  general  hierarchical  constraint  set.  This 
includes  support  of  the  document  types: 


o 

FTAM-1 

"ISO 

FTAM  unstructured  text" 

o 

FTAM- 2 

"ISO 

FTAM  sequential  text" 

o 

FTAM-3 

"ISO 

FTAM  unstructured  binary" 

0 

NBS-6 

"NBS- 

6  FTAM  sequential  file" 

o 

NBS-7 

"NBS- 

7  FTAM  random  access  file 

o 

NBS-8 

"NBS- 

8  FTAM  indexed  file" 

o 

NBS-9 

"NBS- 

9  file  directory  file" 

This  Implementation  Profile  supports  file  transfer  and  not  file 
access,   that  is,   the  ability  to: 

o        read  a  complete  file  or  a  single  FADU  which  is 
identified  by  key  or  by  position 

and/or 

o       write  (replace,  extend,  insert  depending  on  constraint 
set  and  document  type)  to  a  file  or  an  FADU. 

This  Implementation  Profile  is  upwardly  compatible  to  Tl  for  the 
transfer  of  unstructured  files. 


9.19.4        Implementation  Profile  Al :  Simple  File  Access 
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Implementation  Profile  Al  provides  the  function  of  transfer  of 
and  access  to  files  with  unstructured  or  flat  constraint  sets  at 
the  external  file  service  level.     This  includes  support  of  the 
document  types: 

o  FTAM-1  "ISO  FTAM  unstructured  text" 

o  FTAM- 2  "ISO  FTAM  sequential  text" 

o  FTAM- 3  "ISO  FTAM  unstructured  binary" 

o  NBS-6  "NBS-6  FTAM  sequential  file"  (optional) 

o  NBS-7  "NBS-7  FTAM  random  access  file"  (optional) 

This  Implementation  Profile  supports  file  transfer  and  file 
access,  that  is  the  ability  to: 

o        read  a  complete  file  or  FADUs  which  are  identified  by 
position, 

o        write  (replace,  extend,   insert  depending  on  constraint 
set  and  document  type)  to  a  file  or  an  FADU, 

o        locate  and  erase  within  files. 


9.19.5        Implementation  Profile  A2 :     Full  File  Access 

Implementation  Profile  A2  provides  the  function  of  transfer  of 
and  access  to  files  with  unstructured  or  flat  constraint  sets  at 
the  external  file  service  level.     This  includes  support  of  the 
document  types: 


o 

FTAM-1 

"ISO 

FTAM  unstructured  text" 

o 

FTAM- 2 

"ISO 

FTAM  sequential  text" 

0 

FTAM- 3 

"ISO 

FTAM  unstructured  binary" 

o 

NBS-6 

"NBS- 

6  FTAM  sequential  file" 

o 

NBS-7 

"NBS- 

7  FTAM  random  access  file 

o 

NBS-8 

"NBS- 

8  FTAM  indexed  file" 

This  Implementation  Profile  supports  file  transfer  and  file 
access,  that  is,  the  ability  to: 

o        read  from  a  complete  file,  or  from  a  series  of  FADUs 
which  are  identified  by  key  or  by  position, 

o        write  (replace,  extend,   insert  depending  on  constraint 
set  and  document  type)  to  a  file  or  an  FADU, 

o        locate  and  erase  within  files. 
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9.19.6        Implementation  Profile  Ml:  Management 

Implementation  Profile  Ml  provides  the  function  for  an  Initiator 
to  manage  the  files  within  the  Virtual  Filestore,   to  which  access 
is  provided  by  the  Responder.     Management  includes  the  services 
of: 

o        creating  a  file 

o        deleting  a  file 

o        reading  attributes  of  a  file 

o        changing  attributes  of  a  file. 


9 . 20  HARMONIZATION 

The  Implementation  Profiles  for  File  Transfer,  File  Access  and 
Management  correspond  to  the  Profiles  of  SPAG  (Standards  Promotion 
and  Application  Group)   in  Europe,   so  that  interworking  will  be 
possible.     Those  Profiles  are  described  in  the  'Guide  to  the  Use  of 
Standards'    (GUS) ;   they  are  the  basis  for  the  Functional  Standards  as 
defined  by  CEN/CENELEC  (Comite  Europeenne  de  Normalization) . 

Table  9.8.     Implementation  Profiles     (NIST)  and  Profiles  (SPAG/CEN-CLC) 


Implementation  Profile 

SPAG/CEN-CLC 

Tl 

A/111 

T2 

A/112 

T3 

A/113 

Al 

A/122 

A2 

A/123 

Ml 

A/13 
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APPENDIX  B:     CONSTRAINT  SETS 
APPENDIX  C:     ABSTRACT  SYNTAXES 
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APPENDIX  A:     FTAM  DOCUMENT  TYPES 

A. 1  NBS-6  Sequential  file  document  type 

This  object  with  Object  Identifier 

{  iso  identif  ied-organization  icd(9999)  organization-code (1)  docioment- 
type ( 5 )  sequential ( 6 ) ) 

was  withdrawn  on  March  16,   1990.     It  was  replaced  with  the  object  NBS-6 
Sequential  file  document  type  with  the  Object  Identifier 

{iso  identif ied-organization  oiw(14)  ftamsig(5)  document- type (5) 
sequential (6) ) 
defined  in  chapter  9,  A. 5. 

A. 2  NBS-7  Random  access  file 

This  object  with  Object  Identifier 

{iso  identif ied-organization  icd(9999)  organization-code(l)  document- 
type(5)  random-file (7) } 

was  withdrawn  on  March  16,   1990.     It  was  replaced  with  the  object  NBS-7 
Random  access  file  document  type  with  the  Object  Identifier 

{iso  identif ied-organization  oiw(14)  ftamsig(5)  document- type (5) 
random-access (7) ) 
defined  in  chapter  9,  A. 6. 

A. 3  NBS-8  Indexed  sequential  file 

This  object  with  Object  Identifier 

{iso  identif ied-organization  icd(9999)  organization-code(l)  document- 
type(5)  indexed-f ile(8) ) 

was  withdrawn  on  March  16,   1990.     It  was  replaced  with  the  object  NBS-8 
Indexed  sequential  file  document  type  with  the  Object  Identifier 
{iso  identif ied-organization  oiw(14)  ftamsig(5)  document- type (5) 
indexed-file(8) ) 
defined  in  chapter  9,  A. 7. 

A. 4         NBS-9  File  directory  file 

This  object  with  Object  Identifier 

{iso  identif ied-organization  icd(9999)  organization-code(l)  document- 
type(5)  file  directory(9) ) 

was  withdrawn  on  March  16,   1990.     It  was  replaced  with  the  object  NBS-9 
File  directory  file  document  type  with  the  Object  Identifier 
{iso  identif ied-organization  oiw(14)  ftamsig(5)  document -type (5)  file- 
directory  (9)  ) 
defined  in  chapter  9,  A. 8. 
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A. 5  NBS-6  Sequential  file  document  type 

1.  Entry  Number:  NBS-6 

2.  Information  objects 
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Table  9.9.     Information  objects  in  NBS-6 


1 

document  type  name 

1 

{iso  identif ied-organization  oiw(14) 

f tamsig(5)  ted(-9999V -organization-eode(-l) 

document -type (5)  sequential (6) } 

"NBS-6  FTAM  sequential  file" 

abstract  syntax  names: 

{iso  identif ied-organization  oiw(14) 

a)  name  for  asnamel 

f tamsig(5)  ted(-999)- -organizatton-eode(^l) 

abstract-syntax(2)  nbs-asl(l)} 

"NBS  abstract  syntax  ASl" 

b)  name  for  asname2 

{iso  standard  8571  abstract-syntax(2)  ftam- 

fadu(2) ) 

"FTAM  FADU" 

transfer  syntax  names: 

{ j oint- iso-ccitt  asnl(l)  basic-encoding(l) 

}       "Basic  Encoding  of  a  single  ASN.l  type" 

parameter  syntax: 

PARAMETERS  : :=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl ,  Parameter2} 

ParameterO  : :=     [0]   INTEGER  {univer-time  (23), 

gen- time  (24) , 

boolean  (1) , 

null  (5)  } 

Parameterl     : :=  [1]  SEQUENCE  { 

universal-class-number-1  INTEGER  {   int  (2), 

bit  (3), 

ia5  (22), 

graphic     (25) , 

general     (27) , 

octet          (4) } , 

string- length  INTEGER  } 

Parameter2     : :=  [2]  SEQUENCE  { 

private-class-number  INTEGER  {float  (0)), 

length- 1  INTEGER, 

length- 2          INTEGER  } 

file  model 

{iso  standard  8571  f ile-model(3) 

hierarchical(l) ) 

"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4) 

sequential-flat (2) ) 

"FTAM  sequential  flat  constraint  set" 

file  contents: 

Datatypel   : :=  PrimType  --  as  defined  in  Appendix  C.3 

Annex  -9A ,-  -Part  -3 

Datatype2  : := 

Node -Descriptor -Data -Element 
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3.  Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for 
transfer  and  access  by  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  Virtual 

Filestore. 

4.  References 

ISO  8571,   Information  Processing  Systems  -  Open  Systems 
Interconnection  -  File  Transfer,  Access  and  Management 

5 .  Definitions 

,   This  definition  makes  use  of  the  terms  data  element,  data  unit  and 
file  access  data  unit  as  defined  in  ISO  8571-1. 

6.  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

7 .  Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units, 
each  of  which  consists  of  zero,  one  or  more  data  elements.     The  order 
of  each  of  these  elements  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM 
hierarchical  file  model  as  constrained  by  the  sequential  flat 
constraint  set  (see  table  9.9)     These  definitions  appear  in  ISO  8571- 
2.     As  additional  constraints  FADU  identity  will  be  limited  to 
'begin',    'end',   'first'  and  'next'. 

For  a  specific  file  the  number  of  data  elements  in  a  data  unit  is 

given  by  the  parameters.     Each  data  element  is  a  data  type  from  the 
I        set  of  primitive  data  types  defined  in  the  Appendix  C.3  Annex -9A ,- -Part 
I        3  of  this  document.     Each  data  unit  contains  the  same  data  element 

types  in  the  same  order  as  all  other  data  units.     These  types  are 

determined  by  the  parameters  0  through  2. 

The  string  length  field  of  Parameterl  specifies  the  length  of  the 
value  in  octets  for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types. 
For  character- type  data  elements,  the  string- length  indicates  the 
actual  number  of  characters  from  the  specified  character  set,  not 
including  any  escape  sequences  or  overhead  from  the  character 
encoding. 

For  floating  point  numbers,  finite  form,   length- 1  and  length- 2 
specify  the  length  in  bits  of  mantissa  and  exponent,  respectively. 
The  length- 1  and  length-2  values  are  irrelevant  for  the  other  choices 
of  floating  point  numbers. 
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8.  Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically 
structured  file  as  defined  in  the  ASN.l  module  IS08571 -FADU  in  ISO 
8571,   in  which  each  of  the  file  access  data  units  has  the  abstract 
syntactic  structure  of  NBS-ASl  as  defined  by  the  parameters. 

9,  Definition  of  transfer 

9.1  Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  9.9,  where  the  PrimType  in 
the  datatype  is  given  by  the  NBS-ASl  definition;  or 

b)  Datatype2  defined  in  table  9.9,   the  ASN.l  datatype 
declared  as  "Data-Element"  in  the  ASN.l  module  IS08571- 
FADU. 

9 . 2  Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data 
values,  each  of  which  is  either 

a)  one  value  of  the  ASN.l  datatype  "Datatypel,"  carrying 
one  of  the  data  elements  from  the  document.     All  values 
are  transmitted  in  the  same  (but  any  )  presentation 
context  defined  to  support  the  abstract  syntax  name 
"asnamel"  or 

b)  a  value  of  "Datatype2."    All  values  are  transmitted  in 
the  same  (but  any)  presentation  context  defined  to 
support  the  abstract  syntax  name  "asname2." 

Notes : 

1.  Specific  carrier  standards  may  impose  additional  constraints 
on  the  presentation  context  to  be  used,  where  the  above 
permits  a  choice 

2.  Any  document  type  defined  in  this  entry  either  makes  no  use 
of  Datatype2 ,  or  starts  with  a  Datatype2  transmission. 

Boundaries  between  presentation  data  values  in  the  same 
presentation  context,  and  boundaries  between  P-DATA  primitives, 
are  chosen  locally  by  the  sending  entity  at  the  time  of 
transmission,  and  carry  no  semantics  of  the  document  type. 
Receivers  which  support  this  document  type  shall  accept  a 
document  with  any  of  the  permitted  transfer  options  (e.g., 
document  type  parameters  and  transfer  syntaxes). 
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9 . 3  Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the 
sequence  of  presentation  data  values  of  types  a)  and  b)   is  the 
same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and 
Data  Units  in  the  hierarchical  structure,  when  flattened 
according  to  the  definition  of  the  hierarchical  file  model  in  ISO 
8571-2. 

10.  Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the 
transfer  syntax  generation  rules  named  in  table  9.9  for  all 
presentation  data  values  transferred.     An  implementation  may 
optionally  support  other  named  transfer  syntaxes. 

11.  ASE  specific  specifications  for  FTAM 

11.1  Simplification  and  relaxation 
11.1.1     Structural  simplification 

This  simplification  loses  information. 

The  document  type  NBS-6  may  be  simplified  to  the  document  type 
FTAM-3  (allowed  only  when  reading  the  file) .     The  octet 
representation  of  the  transferred  data  is  unpredictable.     It  will 
usually  correspond  to  the  data  values  as  stored  in  the  local  Real 
Filestore  of  the  Responder, 

11.2  Access  context  selection 

A  document  of  type  NBS-6  may  be  accessed  in  any  one  of  the  access 
contexts  defined  in  the  sequential  flat  constraint  set.  The 
presentation  data  units  transferred  in  each  case  are  those 
derived  from  the  structuring  elements  defined  for  that  access 
context  in  ISO  8571-2. 

11.3  The  INSERT  operation 

When  the  <INSERT>  operation  is  applied  at  the  end  of  file  the 
transferred  material  shall  be  the  series  of  FADUs  which  would  be 
generated  by  reading  any  NBS-6  document  with  the  same  parameter 
values  in  access  context  FA. 
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1.  Entry  nijmber:  NBS-7 

2.  Information  objects 
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Table  9.10.     Information  objects  in  NBS-7 


document  type  name 

{iso  identif ied-organization  oiw(14) 

f tamsig(5)  ted(^9999> - -organtzati:on-eode(-lr) 

document -  type ( 5 )  random- f  i le ( 7 ) ) 

"NBS-7  FTAM  random  access  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identif ied-organization  oiw(14) 

f tamsig(5)  ied(^9999> -organtzation-eodef t) 

abstract- S3mtax( 2)  nbs-asl(l)} 

"NBS  abstract  syntax  ASl" 
{iso  standard  8571  abstract-syntax(2)  ftam- 
fadu(2))                    "FTAM  FADU" 

transfer  syntax  names: 

{ joint-iso-ccitt  asnl(l)  basic-encoding(l) 
}        "Basic  Encoding  of  a  single  ASN.l  type" 

parameter  syntax: 

PARAMETERS  : :=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl,  Parameter2} 
ParameterO  : :=     [0]  INTEGER  {univer-time  (23), 

gen- time  (24) , 
boolean  (1) , 
null  (5)  ) 

Parameterl     : :=  [1]  SEQUENCE  { 

universal-class-number- 1  INTEGER  {  int  (2), 

bit  (3), 
ia5  (22), 
graphic  (25), 
general     (27) , 
octet          (4) ) , 

string- length  INTEGER  } 
Parameter2     : :=  [2]  SEQUENCE  { 

private-class-number  INTEGER  {float  (0)}, 
length- 1  INTEGER, 
length- 2          INTEGER  } 

file  model 

{iso  standard  8571  f ile-model(3) 
hierarchical(l) ) 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  identif ied-organization  oiw(14) 
f tamsig(5)  iedf 9999)- -organization -eodeft) 
constraint-set (4)  nbs  ordered-f lat(l) ) 
"NBS  ordered  flat  constraint  set" 

file  contents: 

Datatypel  : := 
Datatype2  :  :  = 

PrimType  --  as  defined  in  Appendix  C.3 
Annex  -9A ,-  -Part  -3 

CHOICE      {  Node-Descriptor-Data-Element, 
Enter-Subtree-Data-Element  ) 
Exit-Subtree-Data-Element  ) 
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3.  Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for 
transfer  and  access  by  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  Virtual 
Filestore . 

4 .  References 

ISO  8571,   Information  Processing  Systems  -  Open  Systems 
Interconnection  -File  Transfer,  Access  and  Management 

5 .  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and 
file  access  data  unit  as  defined  in  ISO  8571-1. 

6 .  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

7 .  Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units, 
each  of  which  consists  of  zero,  one  or  more  data  elements.     The  order 
of  each  of  these  elements  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM 
hierarchical  file  model  as  constrained  by  the  NBS -ordered- flat 
constraint  set  (see  table  9.10).     These  definitions  appear  in 
Appendix  B.2  9A,--Part-2  of  this  document. 

For  a  specific  file  the  number  of  data  elements  in  a  data  unit  is 
given  by  the  parameters.     Each  data  element  is  a  data  type  from  the 
set  of  primitive  data  types  defined  in  the  Appendix  C.3  Annex -9A ,- -Part 
S  of  this  document.     Each  data  unit  contains  the  same  data  element 
types  in  the  same  order  as  all  other  data  units.     These  types  are 
determined  by  the  parameters  0  through  2. 

The  string  length  field  of  Parameterl  specifies  the  length  of  the 
value  in  octets  for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types. 
For  character- type  data  elements,  the  string- length  indicates  the 
actual  number  of  characters  from  the  specified  character  set,  not 
including  any  escape  sequences  or  overhead  from  the  character 
encoding. 

For  floating  point  numbers,  finite  form,   length- 1  and  length- 2 
specify  the  length  in  bits  of  mantissa  and  exponent,  respectively. 
The  length- 1  and  length-2  values  are  irrelevant  for  the  other  choices 
of  floating  point  numbers. 
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8.  Abstract  syntactic  structure 


The  abstract  syntactic  structure  of  the  document  is  a  hierarchically 
structured  file  as  defined  in  the  ASN.l  module  IS08571-FADU  in  ISO 
8571,   in  which  each  of  the  file  access  data  units  has  the  abstract 
syntactic  structure  of  NBS-ASl  as  defined  by  the  parameters. 


9.  Definition  of  transfer 
9.1  Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  9.10,  where  the  PrimType  in 
the  datatype  is  given  by  the  NBS-ASl  definition;  or 

b)  Datatype2  defined  in  table  9.10,   the  ASN.l  datatype 
declared  as  "Data-Element"  in  the  ASN.l  module 
IS08571-FADU. 


9 . 2  Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data 
values,  each  of  which  is  either 

a)  one  value  of  the  ASN.l  datat3rpe  "Datatypel,"  carrying 
one  of  the  data  elements  from  the  document.  All 
values  are  transmitted  in  the  same  (but  any  ) 
presentation  context  defined  to  support  the  abstract 
syntax  name  "asnamel"  or 

b)  a  value  of  "  Datatype2 . "     All  values  are  transmitted 
in  the  same  (but  any)  presentation  context  defined  to 
support  the  abstract  syntax  name  "  asname2." 


Notes:  1.  Specific  carrier  standards  may  impose  additional 
constraints  on  the  presentation  context  to  be 
used,  wheie  the  above  permits  a  choice 

2.  Any  document  type  defined  in  this  entry  either 
makes  no  use  of  Datatype2 ,  or  starts  with  a 
Datatype2  transmission. 


Boundaries  between  presentation  data  values  in  the  same 
presentation  context,   and  boundaries  between  P-DATA  primitives, 
are  chosen  locally  by  the  sending  entity  at  the  time  of 
transmission,   and  carry  no  semantics  of  the  document  type. 
Receivers  which  support  this  document  type  shall  accept  a 
document  with  any  of  the  permitted  transfer  options  (e.g., 
document  type  parameters  and  transfer  syntaxes). 
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9 . 3  Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the 
sequence  of  presentation  data  values  of  types  a)  and  b)   is  the 
same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and 
Data  Units  in  the  hierarchical  structure,  when  flattened 
according  to  the  definition  of  the  hierarchical  file  model  in  ISO 
8571-2. 

10.  Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the 
transfer  syntax  generation  rules  named  in  table  9.10  for  all 
presentation  data  values  transferred.     Implementation  may 
optionally  support  other  named  transfer  syntaxes. 

11.  ASE  specific  specifications  for  FTAM 
11.1        Simplification  and  relaxation 
11.1.1    Structural  simplification 


This  simplification  loses  information. 


The  document  type  NBS-7  may  be  accessed  as  a  document  type  FTAM- 3 
(allowed  only  when  reading  the  file)  by  specifying  document  type 
FTAM-3  in  the  <contents  type>  parameter  in  <F-OPEN  request>,  and 
limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is 
unpredictable.     It  will  usually  correspond  to  the  data  values  as 
stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-7  can  be  accessed  as  a  document  of  type 
NBS-6  (allowed  only  when  reading  the  file)  by  specifying  document 
type  NBS-6  with  appropriate  data  type  parameters  in  the  <contents 
type>  parameter  on  the  <F-OPEN  request>. 

11.2  Access  context  selection 

A  document  of  type  NBS-7  may  be  accessed  in  any  one  of  the  access 
contexts  defined  in  the  NBS-ordered-f lat  constraint  set.  The 
presentation  data  units  transferred  in  each  case  are  those 
derived  from  the  structuring  elements  defined  for  that  access 
context  in  ISO  8571-2. 

11.3  The  INSERT  operation 

When  the  <INSERT>  operation  is  applied  at  the  end  of  file  the 
transferred  material  shall  be  the  series  of  FADUs  which  would  be 
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generated  by  reading  any  NBS-7  document  with  the  same  parameter 
values  in  access  context  FA. 
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I  NBS-8  Indexed  sequential  file 

1.  Entry  Number:  NBS-8 

2.  Information  objects 

Table  9.11.     Information  objects  in  NBS-8 


document  tjrpe  name 

{iso  identif ied-organization  oiw(14) 

f tamsig(5)  ied(-9999> -organizatton-eode^-t) 

document  type(5)  indexed-f ile(8) ) 

"NBS-8  FTAM  indexed  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identif ied-organization  oiw(14) 
ftamsig(5)  ted(-9999> -organization -code ft) 
abstract  syntax(2)  nbs-asl(l)) 

"NBS  abstract  sjmtax  ASl" 
{iso  standard  8571  abstract-syntax(2)  ftara- 
fadu(2)} 

"FTAM  FADU" 

transfer  syntax  names: 

{ joint-iso-ccitt  asnl(l)  basic-encoding(l) 
) 

"Basic  Encoding  of  a  single  ASN.l  type" 

parameter  syntax: 

PARAMETERS   : :=  SEQUENCE                     {DataTypes,  KeyType ,  KeyPosition) 

DataTypes     : :=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl ,  Parameter2) 

KeyType        : :=  CHOICE  {ParameterO,  Parameterl,  Parameter2) 

ParameterO,  Parameterl,  Parameter2,  as  defined  for  the 
--     document  tjrpes  NBS-6,  NBS-7 

KeyPosition: :=  INTEGER 

file  model 

{iso  standard  8571  f ile-model(3) 
hierarchical(l) ) 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set (4) 
ordered-flat(3)  } 

"FTAM  ordered  flat  constraint  set" 

file  contents: 

Datatypel  : :=  PrimType  --as  defined  in  Appendix  C.3 

Annex  -9A ,-  -Part  -3 

Datatype2  ::=  CHOICE      {  Node-Descriptor-Data-Element, 

Enter-Subtree-Data-Element  } 
Exit-Subtree-Data-Element  } 
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3.  Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for 
transfer  and  access  using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  Virtual 

Filestore . 

4.  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems 
Interconnection  -File  Transfer,  Access  and  Management 

5 .  Definitions 

This  definition  makes  use  of  the  terms  data  element,   data  unit  and 
file  access  data  unit  as  defined  in  ISO  8571-1. 

6 .  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

7 .  Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units, 
each  of  which  consists  of  zero,  one  or  more  data  elements.     The  order 
of  each  of  these  elements  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM 
hierarchical  file  model  as  constrained  by  the  FTAM  ordered  flat 
constraint  set  (see  table  9.11).     These  definitions  appear  in  ISO 
8571-2. 

The  following  additional  requirements  are  specified  for  the  use  of 
the  ordered  flat  constraint  set: 

o        The  FADU  identities  'first',   'last',  and  'node  number'  are 
not  required  for  conformant  implementations 

o       The  identities  'next'  and  'previous'  are  allowed  for  all 
FADUs 


Each  data  element  is  a  data  type  from  the  set  of  primitive  data  types 
defined  in  Appendix  C.3  9A,--Parfe-3  of  this  document.     Each  data  unit 
contains  the  same  data  element  types  in  the  same  order  as  all  other 
data  units.     These  types  and  their  respective  maximum  lengths  are 
defined  by  the  <DataTypes>  parameter. 

The  string  length  field  of  Parameterl  specifies  the  length  of  the 
value  in  octets  for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types. 
For    character- type    data    elements,    the    string-length    indicates  the 
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actual  number  of  characters  from  the  specified  character  set,  not 
including  any  escape  sequences  or  overhead  from  the  character 
encoding. 

For  floating  point  numbers,  finite  form,  length-1  and  length-2 
specify  the  length  In  bits  of  mantissa  and  exponent,  respectively. 
The  length-1  and  length-2  values  are  Irrelevant  for  the  other  choices 
of  floating  point  numbers. 
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Each  data  unit  in  the  file  has  a  key  associated  with  it,  which  is  the 
user-coded  form  of  Node  Name.     The  key  of  each  data  unit  is  of  the 
same  data  type  as  the  key  of  all  other  data  units  in  the  file  and  is  a 
single  data  element  from  the  set  of  primitive  data  tjrpes  defined  in 
Appendix  C.3  9A,--Part-3. 

The  type  and  length  of  the  key  are  defined  by  the  <KeyType> 
parameter. 

The  primitive  data  types  and  minimum  size  ranges  of  each  unit  which 
an  implementation  must  accept  as  a  key  value  are  given  in  the 
following  table  9.12. 


Table  9.12.     Datat3rpes  for  keys 


Key  Type 

Minimum  Range  (octets) 

Order 

ASN.l  INTEGER 

(1-2) 

increasing  numeric  value 

ASN.l  IA5String 

(1-16) 

lexical  order 

ASN.l  GraphicString 

(1-16) 

lexical  order 

ASN.l  GeneralString 

(1-16) 

lexical  order 

ASN.l  OCTET  STRING 

(1-16) 

increasing  value 

ASN.l  GeneralizedTime 

increasing  time  value 

ASN.l  UniversalTime 

increasing  time  value 

NBS-ASl  FloatingPointNumber 

increasing  numeric  value 

The  position  of  the  key  in  the  data  unit  is  specified  by  the 
<position>  parameter. 

position  =  0  implies  the  key  is  not  part  of  the  data 

position  >  0  specifies  the  actual  data  element  in  the  data  unit. 

8.  Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically 
structured  file  as  defined  in  the  ASN.l  module  IS08571-FADU  in  ISO 
8571,   in  which  each  of  the  file  access  data  units  has  the  abstract 
S3mtactic  structure  of  NBS-ASl  as  defined  by  the  parameters. 

9.  Definition  of  transfer 


9 . 1  Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)      Datatypel  defined  in  table  9.11,  where  the  PrimType  in  the 
datatype  is  given  by  the  NBS-ASl  definition;  or 
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b)       Datatype2  defined  in  table  9.11,   the  ASN.l  datatype 

declared  as  "Data-Element"  in  the  ASN.l  module  IS08571-FADU. 

9.2  Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data 
values,  each  of  which  is  either 

a)  one  value  of  the  ASN.l  datatype  "Datatypel ,"• carrying  one  of 
the  data  elements  from  the  document.     All  values  are 
transmitted  in  the  same  (but  any)  presentation  context 
defined  to  support  the  abstract  syntax  name  "asnamel"  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the 
same  (but  any)  presentation  context  defined  to  support  the 
abstract  syntax  name  "asname2." 

Notes:  1.  Specific  carrier  standards  may  impose  additional 
constraints  on  the  presentation  context  to  be 
used,  where  the  above  permits  a  choice 
2.  Any  document  type  defined  in  this  entry  either 
makes  no  use  of  Datatype2,  or  starts  with  a 
Datatype2  transmission. 

Boundaries  between  presentation  data  values  in  the  same 
presentation  context,  and  boundaries  between  P-DATA  primitives, 
are  chosen  locally  by  the  sending  entity  at  the  time  of 
transmission,  and  carry  no  semantics  of  the  document  type. 
Receivers  which  support  this  document  type  shall  accept  a 
document  with  any  of  the  permitted  transfer  options  (e.g., 
document  type  parameters  and  transfer  syntaxes) . 

9.3  Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the 
sequence  of  presentation  data  values  of  types  a)  and  b)   is  the 
same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and 
Data  Units  in  the  hierarchical  structure,  when  flattened 
according  to  the  definition  of  the  hierarchical  file  model  in  ISO 
8571-2. 

10.  Transfer  syntcix 

An  implementation  supporting  this  document  type  shall  support  the 
transfer  syntax  generation  rules  named  in  table  9.11  for  all 
presentation  data  values  transferred.     Implementation  may 
optionally  support  other  named  transfer  syntaxes. 

11.  ASE  specific  specifications  for  FTAM 
11.1        Simplification  and  relaxation 
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11.1.1    Structural  simplification 

This  simplification  loses  information. 

The  document  type  NBS-8  may  be  accessed  as  a  document  type  FTAM-3 
(allowed  only  when  reading  the  file)  by  specifying  document  type 
FTAM-3  in  the  <contents  type>  parameter  in  <F-OFEN  request>,  and 
limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is 
unpredictable.     It  will  usually  correspond  to  the  data  values  as 
stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-8  can  be  accessed  as  a  document  of  type 
NBS-6  (allowed  only  when  reading  the  file)  by  specifying  document 
type  NBS-6  with  appropriate  data  type  parameters  in  the  <contents 
type>  parameter  on  the  <F-OPEN  request>.     The  traversal  order  of 
I         the  FADUs  must  be  maintained. 

Note:  The  traversal  order  is  as  reading  the  file  as  NBS-8  in 

key  order. 

11.2  Access  context  selection 

A  document  of  type  NBS-8  may  be  accessed  in  any  one  of  the  access 
contexts  defined  in  the  FTAM  ordered  flat  constraint  set.  The 
presentation  data  units  transferred  in  each  case  are  those 
derived  from  the  structuring  elements  defined  for  that  access 
context  in  ISO  8571-2. 

11.3  The  INSERT  operation 

When  the  <INSERT>  operation  is  applied  the  transferred  material 
shall  be  the  series  of  FADU  which  would  be  generated  by  reading 
any  NBS-8  document  with  the  same  parameter  values  in  access 
context  FA. 

The  insertion  of  a  new  FADU  after  an  already  existing  FADU  will 
be  indicated  via  a  diagnostic  on  TRANSFER-END. 

11.4  The  EXTEND  operation 

This  operation  is  excluded  for  the  use  with  this  document  type. 
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1.  Entry  Number:  NBS-9 

2.  Information  objects 


March  1990  (Stable) 


9-59 


March  1990  (Stable) 


Table  9.13.     Information  objects  in  NBS-9 


document  type  name 

{ iso  identif ied-organization  oiw(14) 

f tamsig(5)  tedf 9999>  -organization -eode(-t) 

*  4  life  LL\^          r     \     /     ■X-'i-'i-C?    \x  d.  1.                y  \  ^  /  / 

"NBS-9  FTAM  file  directory  file" 

abstract  syntax  names: 

{iso  identif ied-organization  oiw(14) 
f tamsig(5)  (^9999> -organizafeton-eodefl) 
abstract-syntax(2)  nbs-as2(2)) 
"NBS  file  directory  entry  abstract  sjmtax" 

transfer  syntax  names : 

{ j oint- iso-ccitt  asnl(l)  basic-encoding(l) ) 
"Basic  Encoding  of  a  single  ASN.l  type" 

parameter  syntax 


PARAMETERS  : :=     [0]  IMPLICIT  BIT  STRING  { 


--  Kernel  group 


read-filename  (0), 
read-permitted-actions  (1), 
read- content s -  type  ( 2 ) , 


--  Storage  group 

read-storage-account  (3), 
read-date-and-time-of -creation  (4) , 
read-date-and-time-of -last-modification  (5) , 
read-date-and-time-of -last-read-access  (6) , 
read-date-and- time -of -last -at tribute -modification( 7) , 
read- identity-of -creator  (8), 
read- identity-of- last-modifier  (9) , 
read-identity-of-last-reader  (10) , 
read-identity-of-last-attribute-modifier  (11) , 
read-file-availability  (12), 
read-f ilesize  (13), 
read- future- files ize  (14), 

--  Security  group 


read-access-control  (15), 
read- legal-qualifications  (16), 

Private  group 


read-private-use  (17)  ) 


(Continued  on  next  page.) 
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file  model 

{iso  standard  8571  f ile-model(3) 
hierarchical ( 1 ) } 
"FTAM  hierarchical  file  model" 

constraint-set 

{iso  standard  8571  constraint-set (4) 
unstructured(l) ) 
"FTAM  unstructured  constraint  set" 

File  contents: 

Datatjrpel  :  :=  FileDirectoryEntry 

--As  defined  by  NBS-AS2  in  Appendix  A, 
--C.4  Part -3  of  this  document 

3.  Scope  and  field  of  Application 

This  document  defines  the  contents  of  a  file  for  transfer  (not  for 
storage)  using  FTAM. 

4.  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems 
Interconnection  -File  Transfer,  Access  and  Management. 

5 .  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and 
file  access  data  unit  as  defined  in  ISO  8571-1 

6 .  Abbreviations 

FTAM  File  Transfer,  Access  and  Management. 

7.  Docijment  Semantics 

The  document  consists  of  one  file  access  data  unit,  which  consists 
only  of  zero,  one  or  more  data  elements  of  type  <FileDirectoryEntry> 
(defined  in  NBS-AS2) . 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM 
hierarchical  file  model  as  constrained  by  the  unstructured  constraint 
set.     These  definitions  appear  in  ISO  8571-1. 

The  parameter  of  the  document  type  is  used  on  <F-OPEN  request>  to 
specify  the  desired  attributes  of  each  of  the  files  on  the  Filestore, 
when  reading  the  document. 

8.  Abstract  syntactic  structure 
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The  abstract  syntactic  structure  of  the  document  is  a  series  of  file 
directory  entries ,  each  of  which  is  defined  by  the 
<FileDirectoryEntry>  definition  in  NBS-AS2. 

Additional  constraints  are  defined  for  this  document  t3^e:  File 
access  actions  are  restricted  to  Read.     File-directory  files  may  not 
be  Written  or  Modified  (except  as  a  side  effect  of  actions  performed 
on  individual  files  contained  within  a  file  directory) . 

9.  Definition  of  transfer 

9.1  Datatype  definition 

The  file  consists  of  zero  or  more  values  of  Datatypel  defined  in 
table  9.13. 

9 . 2  Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data 
values.     Each  presentation  data  value  shall  consist  of  one  value 
of  the  ASN.l  data  type  "Datatypel,"  carrying  one  of  the  file 
directory  entries  from  the  document. 

All  values  are  transmitted  in  the  same  (but  any)  presentation 
context  established  to  support  the  abstract  syntax  name 
"asnamel"  declared  in  table  9.13. 

9 . 3  Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  is  the  same  as  the 
sequence  of  file  directory  entries  within  the  Data  Unit  in  the 
file. 

10.  Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support 
the  transfer  syntax  generation  rules  named  in  table  9.13  for  all 
presentation  data  values  transferred.     Implementations  shall 
optionally  support  other  named  transfer  syntaxes. 

11.  ASK  specific  specifications  for  FTAM 

11.1        Simplification  and  relaxation 

Relaxation  is  allowed  to  any  bitstring  combination  of  the 
document  type  parameter. 
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APPENDIX  B:     CONSTRAINT  SETS 

LJL         NBS  Ordered  flat  constraint  set 

This  object  with  Object  Identifier 

{iso  identif ied-organization  icd(9999)  organization-code (1)  constralnt- 

set(4)  nbs-ordered-flat(l) ) 
was  withdrawn  on  March  16,  1990.     It  was  replaced  with  the  object  NBS 
Ordered  flat  constraint  set  with  the  Object  Identifier 

{iso  identif ied-organization  oiw(14)  ftamsig(5)  constraint-set (4) 

r;i3S-ordered-flat(l) ) 
defined  in  chapter  9,  B.2. 
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Lul         NBS  Ordered  flat  constraint  set  definition 


1.  Field  of  application 

The  NBS -ordered  flat  constraint  set  applies  to  files  which  are 
structured  into  a  sequence  of  individual  FADUs  and  to  which  access 
may  be  made  oh  an  FADU  basis  by  position  in  the  sequence. 

2.  Basle  constraints 


9-6  3 


June  1990  (Stable) 


Table  9.14.     Basic  constraints  for  NBS  Ordered  flat 


Constraint  set  descriptor 

"NBS  ordered  flat  constraint  set" 

Constraint  set  identifier 

{iso  identif ied-organization  oiw(14) 
ttamsigQ J ) 

constraint-set (4)  nbs-ordered- 
I  iat  (.  i ;  J 

Node  name 

None 

File  access  actions 

Locate,  Read,  Insert,  Erase,  Replace 

Qualified  action 

None 

Available  access  contexts 

HA,   FA,  UA 

Creation  state 

Root  node  without  an  associated  data 
unit 

Location  after  open 

Root  node 

Beginning  of  file 

Root  node 

End  of  file 

No  node  selected;    'previous'  gives  last 
node  in  traversal  sequence ,' current ' and 
'next 'give  an  error. 

Read  whole  file 

Read  in  access  context  FA  or  UA  with 
FADU  identity  of  'begin' . 

Write  whole  file  (append) 
Write  whole  file  (replace) 

Transfer  the  series  of  leaf  FADUs  which 
would  be  generated  by  reading  the  whole 
file  in  access  context  FA;  perform  the 
1"'ran«;fet"  with  an  FADU  identitv  of  'end' 
and  a  file  access  action  of  'insert'. 
Transfer  the  series  of  leaf  FADUs  which 
would  be  generated  by  reading  the  whole 
file  in  access-context  HA;  perform  the 
transfer  with  FADU  identity  'begin'  and 
file  action  of  'replace'. 

3.  Structural  constraints 


The  root  node  shall  not  have  an  associated  data  unit;  all  children  of 
the  root  node  shall  be  leaf  nodes  and  may  have  an  associated  data 
unit;   all  arcs  from  the  root  node  shall  be  of  length  one. 

4.  Action  constraints 

Insert :       The  <Insert>  action  is  allowed  only  at  the  end  of  file.  If 
the  FADU  identity  is  'end'  the  new  node  is  inserted 
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following  all  existing  nodes  in  the  file.     If  the  FADU  identity 
is  'node  nvimber'  ,  the  number  must  be  at  least  one  greater  than 
the  node  number  of  the  last  existing  node.     Any  nodes  between  the 
last  existing  node  and  the  new  node  are  empty,   i.e.,  nodes 
without  data.     If  the  FADU  identity  is  a  'node  number'  not 
greater  than  that  of  the  last  existing  node,  an  error  will  occur. 
The  location  following  <insert>  is  'end'. 

Erase :        The  Erase  action  is  only  allowed  at  the  root  node  to  empty 
the  file,  with  FADU  identity  of  'begin'.     The  result  is  a 
solitary  root  node  without  an  associated  data  unit. 

Note:  It  is  the  intention  when  using  this  constraint  set  to  allow 

for  emptying  an  FADU,  i.e.,  leaving  an  FADU  with  a  DU  of 
data  length  0  (or  without  a  DU)  ;  afterwards  data  may  be 
reinserted  into  this  hole.  In  order  to  empty  an  FADU,  the 
<Replace>  operation  may  be  used  with  new  data  of  length  zero 
(or  with  an  FADU  whose  <data  exists>  bit  is  set  to  'false' 
and  no  DU) .  Refilling  the  hole  is  accomplished  by  a 
<Replace>  operation  with  the  new  DU  (or  with  the  new  FADU, 
whose  <data  exists>  bit  is  set  to  'true'  and  the  new  DU) . 

Identity  constraints 

The  FADU  identity  associated  with  the  file  action  shall  be  one  of  the 
identities  'begin',   'end',   'first',   'last',   'current',  'next', 
'previous'  or  a  'node  number'  greater  than  or  equal  to  one.  The 
actions  with  which  these  identities  can  be  used  are  given  in  the 
following  table. 

Table  9.15.     Identity  constraints  in  NBS  Ordered  flat 


Action 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node  No . 

Locate 

valid 

valid 

valid 

valid 

valid 

valid 

valid 

valid 

Read 

whole 

leaf 

leaf 

leaf 

leaf 

leaf 

leaf 

Insert 

leaf 

leaf 

Erase 

whole 

Replace 

whole 

leaf 

leaf 

leaf 

leaf 

leaf 

leaf 
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APPENDIX  C:     ABSTRACT  SYNTAXES 
C. 1  Abstract  Syntax  NBS-ASl 

This  object  with  Object  Identifier 

{iso  identif ied-organization  icd(9999)  organizatlon-code(l)  abstract- 

syntax(2)  nbs-asl(l)) 

was  withdrawn  on  March  16,  1990.     It  was  replaced  with  the  object 

Abstract  syntax  NBS-ASl  with  the  Object  Identifier 

{iso  identif  ied-organization  oiw(14)  ftainsig(5)  abstract- syntax(  2) 

nbs-asl(l) ) 

defined  in  chapter  9,  C.3. 

C.2         Abstract  Syntax  NBS-AS2 

This  object  with  Object  Identifier 

{iso  identif ied-organization  icd(9999)  organization-code (1)  abstract- 

syntax(2)  nbs-as2<2)) 

was  withdrawn  on  March  16,  1990.     It  was  replaced  with  the  object 

Abstract  syntax  NBS-AS2  with  the  Object  Identifier 

{iso  identif ied-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 

nbs-as2(2) ) 

defined  in  chapter  9,  C.4. 
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I  C.  3 


Part -3  ^ - -Abstract -Syntaxes- 

Abstract  Syntax  NBS-ASl  definition 


Abstract  syntax  name 


{ iso  identif ied-organization  oiw(14)  ftamsig(5) 
iedf 9999> -organization-eode(^t)  abstract-syntax(2) 
nbs-asl (1) } 

"NBS  abstract  syntax  ASl" 


This  is  an  abstract  syntax  for  the  set  of  presentation  data  values,  each 
of  which  is  a  value  of  the  ASN.l  type  NBS-ASl . PrimType 


NBS-ASl  DEFINITIONS  : 
BEGIN 

PrimType  : :=  CHOICE  { 


IRV 


Float ingPointNumber 


INTEGER, 
BIT  STRING, 
BOOLEAN , 
lASString, 
Graphic String, 
GeneralString, 
OCTET  STRING, 
UTCTime , 

GeneralizedTime , 
NULL, 

FloatingPointNumber  ) 

The  support  for  lASString  is  the  ISO  646, 

GO  character  set  and  the  ISO  646,  IRV  CO 
set 

The  minimum  level  of  support  for 
GraphicString  is  the  ISO  646,   IRV  GO 
character  set  and  the  8859-1  GO  and  Gl  sets 
The  minimum  level  of  support  for 
GeneralString  is  the  ISO  646,  IRV  GO 
character  set  and  the  8859-1  GO  and  Gl 
character  sets,   and  ISO  646,   IRV  CO  set. 

[PRIVATE  0]         CHOICE  { 

finite  [0]  IMPLICIT  SEQUENCE 
{  Sign, 

mantissa  BIT  STRING, 
first  bit  must  be  1 
exponent  INTEGER) , 
infinity  [1]  IMPLICIT  Sign, 
signalling-nan  [2]   IMPLICIT  NaN, 
quiet-nan  [3]   IMPLICIT  NaN, 
zero  [4]   IMPLICIT  NULL  ) 


Sign 

NaN 

END 


: :=  INTEGER  {  positive  (0),  negative  (1)  ) 
: :=  INTEGER 
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For  this  abstract  syntax  the  following  transfer  syntax  can  be  used 

{ joint-iso-ccitt  asnl(l)  basic-encoding(l) ) 
"Basic  Encoding  of  a  single  ASN.l  type" 

Notes:     1.  The  mantissa  is  a  number  in  the  range  (1/2  <mantissa<l) . 

2.  The  value  is  equal  to  mantissa  *  2  exponent 

3.  The  first  bit  in  the  mantissa  is  most  significant. 

4.  See  IEEE  754  for  definitions  of  terminology,  such  as  NaN. 

5.  A  minimxim  length  range  (in  bits)  is  required  for  the 
components  of  <FloatingPointNumber>,  as  follows:  mantissa 
1-23  bits,  and  exponent  0-8  bits. 

I  Abstract  Syntax  NBS-AS2  definition 

I  Abstract  S3nitax  name:  {  iso  identif ied-organization  oiw(14) 

I  ftamsig(5)  iedf9999)- -organization-eode(-l:) 

abstract-syntax(2)  nbs-as2(2)  } 

"NBS  file  directory  entry  abstract  syntax" 

This  is  an  abstract  syntax  for  the  set  of  presentation  data  values,  each 
of  which  is  a  value  of  the  ASN.l  Type  NBS-AS2 , FileDirectoryEntry . 

NBS-AS2  DEFINITIONS  : := 

BEGIN 

FileDirectoryEntry     : :=[PRIVATE  2]  Read-Attributes 
Read-Attributes  : :=IS08571-FTAM. Read-Attributes 

END 

For  this  abstract  syntax  the  following  transfer  syntax  will  be  used 

{        joint-iso-ccitt  asnl(l)  basic-encoding(l)  ) 

"Basic  Encoding  of  a  single  ASN.l  type" 

I  c . 5         Abstract  Syntax  "FTAM  unstructured  text  abstract  syntax" 

This  abstract  syntax  is  defined  as  DataTypel  (File  Contents)   in  table  19 
of  ISO  8571-2,  Annex  B. 

I  c . 6         Abstract  Syntax  "FTAM  unstructured  binary  abstract  syntax" 


9-67 


March  1990  (Stable) 


This  abstract  syntax  is  defined  as  DataTypel  (File  Contents)  in  table  21 
of  ISO  8571-2,  Annex  B. 

Part  -4  ^  -(-deteted) 

(former  Part  4  deleted) 


9-68 


10. 


March  1990  (Stable) 
ISO  FILE  TRANSFER.  ACCESS  AND  MANAGEMENT  PHASE  3 


Editor's  Note:  The  "NBS"  designation  remains  in  effect  for 
document  types,  abstract  syntaxes,  and  constraint 
sets  defined  in  all  FTAM  agreements  up  to  1/1/89. 
After  1/1/89,  any  new  functionality  references  the 
"NIST"  designation.  This  is  to  reflect  the  change 
in  identifying  organization  from  "NBS"  to  "NIST." 

10.1  INTRODUCTION 

This  section  contains  Implementors  Agreements  based  on  ISO  8571  File 
Transfer,  Access  and  Management.     These  Agreements  define  enhancements 
to  the  Stable  FTAM  Implementation  Agreements  for  OSI  Protocols, 
Version  1,  Edition  1,  December  1987  (FTAM  Phase  2  Agreements,  NBS 
500-150),   including  all  their  subsequent  Errata  changes  as  specified 
in  Version  3,  Edition  1  (NIST  Special  Publication  500-177,  this 
document  ch.  9) . 

Therefore  it  is  assumed  that  the  reader  is  familiar  both  with  the 
contents  of  the  base  standard  ISO  8571  and  its  underlying  layers,  and 
also  with  the  above-mentioned  NIST  FTAM  Phase  2  specifications. 

Phase  2  Agreements  define  six  Implementation  Profiles  which  are  Tl , 
T2 ,  T3 ,  Al ,  A2 ,  and  Ml.     In  order  to  avoid  ambiguity  when  referring  to 
these  Implementation  Profiles  the  above  designations  will  apply  only 
to  Phase  2  functionality,  references  to  Phase  3  enhanced 
Implementation  Profiles  will  be  by  the  addition  of  a'. 3',  i.e.,  T1.3, 
T2.3,  T3.3,  A1.3,  A2 . 3 ,  and  Ml . 3 . 

The  following  sections  specify  the  functionality  of  NIST  OIW  FTAM 
Phase  3 . 

o        Sections  10.2  and  10.9  specify  the  technical  details  of  FTAM 
Phase  3  which  are  defined  in  addition  to  the  functionality  of 
FTAM  Phase  2.     Included  is  also  a  status -overview  regarding 
statements  on  Phase  2/Phase  3  compatibility  and  interworking. 

o        Appendix  A  is  a  Profile  Requirements  List  for  the  Implementation 
Profiles  Tl.3,  T2.3,  Al . 3  and  Ml . 3 ,  summarizing  all  features  of 
FTAM  Phase  3,  including  those  of  FTAM  Phase  2.     This  Profile 
Requirements  List  is  fully  based  on  the  FTAM  PICS  Proforma  ISO 
DIS  8571-5. 

o        Appendix  B  is  an  index  of  Object  Identifiers.     It  is  the  official 
NIST  OIW  REgister  of  NIST  OIW  defined  FTAM  objects.     It  contains 
the  Object  Descriptors  and  Object  Identifiers  for  these  objects, 
including  a  reference  to  the  section  in  the  NIST  OIW  Stable 
Agreements  where  the  respective  object  is  being  defined. 
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o        Appendices  C,  D,  and  E  provide  definitions  for  additional 
document  types,  constraing  sets  and  abstract  syntaxes. 

10.2  SCOPE  AND  FIELD  OF  APPLICATION 

These  Phase  3  Agreements  specify  additional  functionality  to  the  FTAM 
Phase  2  Agreements.     These  additional  functions  include: 

o        Further  specifications  of  document  types, 

o        Specification  for  Restart  Data  Transfer  and  Recovery  functional 
units , 

o        Specification  of  FADU  Locking  functional  unit,  and 

o        More  details  on  Access  Control  and  Concurrency  Control. 

All  Phase  2  systems  are  upward  compatible  to  a  Phase  3  system  and  can 
therefore  interwork  with  it,   if  the  additional  functions  are 
negotiated  out  (e.g.,  use  of  Recovery)  or  not  used  for  the 
interconnection  (e.g.,  additional  features  for  document  types). 

10.3  STATUS 

These  FTAM  Phase  3  Agreements  were  completed  December  15,   1989.  No 
further  enhancements  will  be  made  to  this  version  (see  also  next 
section  ERRATA) . 

The  following  tables  summarize  the  functions  and  features  which  are 
defined  for  FTAM  Phase  3  in  addition  to  the  FTAM  Phase  2 
specifications.     They  also  state  the  degree  of  possible  interworking 
and  the  backward  compatibility. 
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Table  10.0(a).     Phase  2/Phase  3  Interworking 


Additional  Requirements 
in  FTAM  Phase  3 

Backward  Compatibility 
to  FTAM  Phase  2 

FTAM-1:     Graphics tring,  VisibleString 
FTAM-2:  VisibleString 

concurrency- control  parameter  for  Initiator 
create-password  parameter  for  Initiator 

Profile  Ml . 3 :     Requires  support  of 

(1)  -T  service  class  including  Limited  File 
Management  FU,  Enhanced  FM  FU; 

TM  service  class  including  Enhanced 
FM  FU  or 

(2)  -A  service  class  including  Limited  File 
Management  FU,  Enhanced  FM  FU 

full  backward  compati- 
bility if  the  additional 
features  of  Phase  3  are 
not  being  used  (character 
sets  in  FTAM-1,   -2),  or 
not  requested  by  an 
Initiator  (functional 
units)  or  not  required 
by  a  Responder 
(parameters)  not  requested 
by  an  Initiator 
(functional  units) 
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Table  10.0(b).     Phase  2/Phase  3  Interworking  (continued) 


Additional  Optional  Features 
in  FTAM  Phase  3 

Backward  Compatibility 
to  FTAM  Phase  2 

FTAM-2:     Generals tring,  lASString 

FTAM- 4 

NBS-8  in  T2.3,  Al . 3 

NBS-9  in  A1.3,  A2.3 

NBS-10 

NBS-11 

NBS-12 

Recovery  functional  unit 

Restart-data- transfer  functional  unit 

FADU- locking  functional  unit  and  FADU- 
lock  parameters  in  Al . 3 ,  A2 . 3 

concurrency-control  parameters  for 
Responder 

full  backward  compati- 
bility if  the  additional 
features  of  Phase  3  are 
not  requested,  negotiated 
out  or  not  being  used 

create -password  parameter  for  Responder 

location-field  of  access -control  element 

suggested-delay  term  of  diagnostic 
parameter  supported  conditionally  on 
Recovery  or  -Restarfe-data-transf er 
functional  units 
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Table  10.0(c).     Phase  2/Phase  3  Interworking  (continued) 


Relaxation  for  FTAM  Phase  3 

to  FTAM  Phase  2 

Profiles  A1.3,  A2.3  do  not  require 
transfer  service  class 

no  minimum  requirement  for  maximum- string- 
length  parameters  for  document  types 

if  T  service  class  not 
being  used 

if  a  Phase  3  system  stays 
below  this  minimum 
requirement 

10.4  ERRATA 


Mn      CW  I7PRATA 

TVPF 

REFERENCED 

nnr'TTvrPMT 
UULiUriEjJN  i 

DJljO  i  lUJN 

CP  3/90-1 

TECHNICAL 

NIST-SP 
500-177 

A.  9,  A. 13 

B.  l,  B.2.1 

NBS-6,  NBS-7, 
NBS-8,  NBS-9, 
NBS-ASl,  NBS-AS2, 
NBS-ordered- 
flat  constraint 
set  with  Obj  Id. 
using  icd(9999) 
withdrawn. 

Above  FTAM  objects 
newly  defined  with 
Obj .  Id.  using 
oiw(14)  ftamsig(5) 

CP  3/90-3 

EDITORIAL 

Appendices 
C,  D,  E 

structuring  into 
subsections,  all 
references  to  these 
definitions  up- 
dated accordingly 

CP  3/90-5 

TECHNICAL 

10.8.5.2 

support  of 
suggested- delay 
field  of  diagnostic 
not  conditional 
on  Restart-data- 
transfer 
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10. 5  CONFORMANCE 

In  addition  to  the  specific  requirements  specified  in  the  following 
subsections,  conformance  to  this  Phase  3  specification  requires 

o        conformance  to  ISO  8571:  1988 

o        conformance  to  Phase  2  FTAM,  unless  specified  otherwise  in  this 
chapter  10. 


10.5.1        Conformance  for  Access  Profiles 

The  access  Profiles  Al . 3  and  A2 . 3  do  not  include  the  requirement 
for  transferring  files  using  the  File  Transfer  service  class. 


10.6  ASSUMPTIONS 


FTAM  Phase  3  Agreements  specify  additional  functionality  to  the 
Implementation  Profiles  Tl ,  T2 ,  T3 ,  Al ,  A2 ,  and  Ml  as  defined  in  the 
FTAM  Phase  2  Agreements.     So  all  definitions  and  requirements  for 
these  Implementation  Profiles  apply  also  to  the  Phase  3  Agreements. 


10.7  FILESTORE  AGREEMENTS 


10.7.1        Document  Types 

In  addition  to  the  Phase  2  Document  Type  Agreements  the  document 
types  FTAM-4  (see  ISO  8571-2,  Annex  B)  and  NBS-10,  NBS-11,  NBS-12 
(see  Appendix  C)  are  defined  for  optional  support. 

Table  10.1  gives  the  support  levels  for  all  document  types  with 
respect  to  the  Implementation  Profiles, 

For  FTAM-1,  FTAM-2,  FTAM-3  and  FTAM-4  the  supported  parameter 
values  for  <universal  class  number>  and  <string  signif icance>, 
respectively  are  listed.     Other  values  are  outside  the  scope  of 
these  Agreements.     No  restriction  or  minimum  requirement  is 
defined  for  the  <maximum  string  length>  parameter  of  these 
document  types . 
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Table  10.1.     Implementation  Profiles  and  Document  Types 
(a)     FTAM-1  Through  FTAM-4 


Implementation 
Profile 
(Note  1) 

Document 
Type 

Universal 
Class  Number 
(Notes  1,   3,  4,  5) 

String 

Significance 

T1.3,  T2.3,  T3.3, 
A1.3,  A2.3 

FTAM-1 

Graphic  String  (25) 

'variable'  'fixed' 

VisibleString  (26) 

'variable'  'fixed' 

GeneralString  (27) 

' not- significant ' 

lASString  (22) 

' not- s  ignif icant ' 

T2.3,  T3.3,  A1.3, 
A2.3 

FT AM -2 

GraphicString  (25) 

' not- significant ' 

VisibleString  (26) 

' not- significant ' 

[GeneralString  (27)] 

' not-signif icant ' 

[IA5String  (22)] 

'not- significant ' 

T1.3,  T2.3,  T.3.3, 
A1.3,  A2.3 

FTAM-3 

' not-signif icant ' 

[T2.3],  [T3.3], 
[A1.3],  [A2.3] 

FTAM-4 

' not- s  ignif icant ' 
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Table  10.1.     Implementation  Profiles  and  Document  Types 
(b)     NBS-6  Through  NBS-11 


Implementation 
Profile  (Note  1) 

Document 
Type 

[T2.3] ,  T3.3, 
(Al.3] .  A2.3 

NBS-6 

[T2.3] .  T3.3. 
[Al.3] .  A2.3 

NBS-7 

(T2.3] ,  T3.3 
(Al.3] ,  A2.3 

NBS-8 

[T1.3],  [T2.3]. 
[T3.3],    [Al.3] , [A2.3] 

NBS-9 

[T2.3],  [T3.3] 
[Al.3],  (A2.3] 

NBS-10 

[T2.3],  (T3.3] 
[Al.3],  [A2.3] 

NBS-11 

Table  10.1.     Implementation  Profiles  and  Document  Types 
(c)  NBS-12 


Implementation 
Profile 
(Note  1) 

Document 
Type 

Universal 

Class 

Number 

Character-Set 
Escape  Sequences 
as  defined  for 
Reg.  Numbers 
CO      GO  Gl 

String- 
Significance 

[T2.3].  [T3.3] 
[Al.3],  [A2.3] 

NBS-12 

lASString  [22] 

(parameter  absent) 

' variable ' 

' fixed' 

See 

Note  6 

GraphicString(25] 

(parameter  absent) 

'variable' 

'fixed' 

GraphicString[25] 

6  100 

'variable' 

' fixed' 

VisibleString[26] 

(parameter  absent) 

'variable ' 

' fixed' 

GeneralString[27] 

(parameter  absent) 

'variable ' 

' fixed' 

GeneralString[27] 

1        6  100 

'variable ' 

' fixed' 

1 
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Notes:  1.  Brackets  around  a  Profile  designator  or  a 
parameter  value  indicate  that  the  respective 
document  type  or  parameter  value  is  optionally 
supported  in  this  Implementation  Profile. 

2.  The  support  level  for  document  types  in 
Implementation  Profile  Ml .  3  depends  on  the  T-  or 
A- Implementation  Profile,  in  conjunction  with 
which  Ml . 3  is  implemented. 

3.  The  support  for  IA5  String  is  the  ISO  646,  IRV  GO 
character  set  and  the  ISO  646,   IRV  CO  set. 

4.  The  minimum  level  of  support  for  Graphic  String  is 
the  ISO  646,  IRV  GO  character  set  and  the  8859-1 
GO  and  Gl  sets. 

5.  The  minimum  level  of  support  for  General  String  is 
the  ISO  646,  IRV  GO  character  set  and  the  8859-1 
GO  and  Gl  sets,  and  ISO  646,   IRV  CO  set. 

6.  If  the  Character- Set  parameter  is  absent,  the 
following  defaults  apply: 


Universal -Class -Number 

Default  Registration  Numbers 
CO               GO  Gl 

lASString  [22] 
GraphicString  [25] 
VisibleString  [26] 
GeneralString  [27] 

1  2 
2 
2 

1  2 

Character-Sets  and  Escape  Sequences: 


Registration 

Content 

Escape 

Number 

Sequence 

1 

CO  set  of  ISO  646 

ESC  2/1  4/0 

2 

ISO  646,  IRV 

6 

ISO  646,  USA  Version-X  3.4  -  1968 

ESC  2/8  4/2 

(Left-hand  part  of  ISO  8859-1) 

100 

Right-hand  part  of  Latin  Alphabet  No  1 

ESC  2/13  4/1 

ISO  8859-1,  ECMA-94 

10.7.2        FADU  Identities 
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In  addition  to  the  Phase  2  FADU  Identity  Agreements  the  following  is 
specified: 

For  the  document  type  NBS-11  used  in  conjunction  with  the 
Transfer  service  class  or  the  Transfer  and  Management  service 
class,   the  support  of  the  FADU  identities  of  'current',  'next', 
'previous'   and  'end'   is  outside  the  scope  of  these  Agreements. 

10.7.3        Access  Control  Attribute 

The  location  field  of  access  control  element  is  optionally  supported. 
It  is  the  implementor ' s  choice  which  combinations  of  fields  in  an 
access  control  element  are  supported.     The  ACE  combination  should  be 
stated  in  the  PICS. 

10. 8  PROTOCOL  AGREEMENTS 


10.8.1  Implementation  Profile  Ml . 3 

The  functions  defined  for  the  Implementation  Profile  Ml . 3  shall  always 
be  implemented  in  conjunction  with  one  or  more  of  the  Implementation 
Profiles  T1.3,  T2 . 3 ,  Al . 3 ,  or  A2 . 3 .     The  service  classes  and  functional 
units  that  shall  be  implemented  are  specified  in  section  10.10, 
Appendix  A,  A. 12.4  and  A. 12. 5. 

For  an  implementation  supporting  the  Profile  Ml . 3  in  conjunction  with 
Tl . 3  or  T2 . 3 ,  any  of  the  service  classes  Transfer,  Management  or 
(Transfer,  Management,  Transf er-and-Management)  may  be  requested  and 
any  of  the  classes  Transfer,  Management,  Transfer-and-Management  may  be 
responded  on  F- INITIALIZE . 

For  an  implementation  supporting  the  Profile  Ml . 3  in  conjunction  with 
Al . 3  or  A2 . 3 ,   any  of  the  service  classes  Access  or  Management  may  be 
requested  and  responded  on  F- INITIALIZE . 

10. 8 . 2  Functional  Units 

For  FTAM  Phase  3  implementations  Recovery  and  Restart  Data  Transfer  are 
optionally  supported. 

FADU  locking  is  optionally  supported  for  Implementation  Profiles  Al . 3 
and  A2.3. 


10.8.3        Implementation  Information  Parameter 
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In  addition  to  the  Agreements  as  specified  for  FTAM  Phase  2,  section 
9.12  ,  the  following  value  is  defined 

NBS- Phases. 


10.8.4  F- Check 

In  order  to  maximize  interoperability,  implementations  of  FTAM  service 
providers  should  not  restrict  the  amount  of  data  transmitted  between 
successive  F-CHECK  requests  to  a  single  quantity.     Variations  in  the 
amount  of  data  transmitted  between  checkpoints  may  be  required  to 
accommodate  differences  in  real  end  systems  supporting  FTAM  Virtual 
Filestores  and/or  in  the  communications  media  underlying  FTAM 
associations.     It  is  required  that  all  FTAM  implementations  are  able  to 
receive  at  least  one  PSDU  between  checkpoints. 

10.8.5  Error  Recovery 

Procedures  for  Class  I,   II  and  III  errors  are  defined  and  supported  for 
FTAM  Phase  3  implementations.     It  is  the  implementor ' s  choice  whether 
to  handle  class  I  errors  using  F-RESTART  PDUs  or  whether  to  use  the 
class  II  error  procedure. 

10.8.5.1  Docket  Handling 

When  a  class  III  error  occurs,  the  length  of  time  a  docket  is 
maintained  is  determined  by  the  local  system.     Recovery  from  a 
class  III  error  is  only  possible  as  long  as  both  end  systems 
maintain  the  docket. 

It  is  also  a  local  decision  how  many  dockets  can  be  maintained 
simultaneously. 

10.8.5.2  Parameters  for  Error  Recovery 

o        The  semantics  of  the  <FTAM  quality  of  service>  parameter  is 
as  defined  in  ISO  8571,   including  the  local  knowledge  of 
FERPM. 

o        No  minimum  requirement  for  the  <checkpoint  window>  parameter 
or  the  checkpoint  size  is  defined. 

o        For  the  <recovery  mode>  parameter  of  F-OPEN,  the  values 

'none'  and  ' at-start-of-transfer '  are  supported.     The  value 
' at-any-active-checkpoint '  is  optionally  supported.  If 
recovery  mode  'at-start-of-transfer'   is  negotiated,  no  F- 
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CHECK  shall  be  issued.     When  recovering  at  the  start  of  the 
transfer,   the  <recovery  point>  value  of  0  shall  be  used. 

o        It  is  required  that  Responders  implementing  the  Restart-data- 
transfer  or  the  Recovery  functional  unit  must  be  able  to 
negotiate  <recovery  mode>  parameter  to  a  value  other  than 
' none ' . 

o        For  the  <diagnostic>  parameter  of  F- INITIALIZE ,  F-P-ABORT  and 
F-RECOVER  PDUs,  the  term  <suggested  delay>  shall  be  supported 
if  the  Recovery  or -Resfeart-data-fcifansf er  functional  units  is 
are  implemented.     The  Basic  FERPM  should  wait  at  least  the 
amount  of  time  as  given  by  the  <suggested  delay>  term  before 
attempting  to  recover. 

10.8.6        Concurrency  Control 

10.8.6.1  Concurrency  Control  to  whole  file 

The  <concurrency  control>  parameters  of  F-SELECT,  F-CREATE  and  F- 
OPEN  with  or  without  the  <access  control>  attribute  of  Security 
Group  are  supported  for  Initiators  and  optionally  supported  for 
Responders . 

If  supported  by  a  Responder,  details  of  their  possible  usage  is  a 
local  matter  and  shall  be  specified  in  the  PICS . 

Default  values  for  concurrency  control  are  as  specified  for  FTAM 
Phase  2  Agreements . 

No  minimum  requirement  is  defined  for  <concurrency  control> 
parameter  values. 

For  a  first  accessor  either  the  specified  concurrency  locks  or  the 
default  values  are  assigned.  For  a  subsequent  accessor  the  access 
to  a  file  is  granted  only  if  this  concurrency  control  requirement, 
as  specified  in  this  concurrency  control  parameter  or  given  by  the 
default  values,  can  be  met.  Otherwise  the  subsequent  request 
shall  be  rejected. 

10.8.6.2  FADU  Locking 

FADU  locking  functional  unit  and  the  respective  <FADU  lock> 
parameters  are  optionally  supported  for  the  Implementation 
Profiles  Al . 3  and  A2 . 3 . 
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It  is  understood  that  ISO  8571-4  Clause  18.4  also  applies  to  FADU 
locks;   that  means  that  as  long  as  a  docket  is  maintained,  FADU 
locks  locking  any  FADUs  recorded  in  that  docket  should  be 
maintained . 

10 ■ 8 . 7        Create  Password 

The  <create  password>  parameter  for  an  implementation  acting  as  an 
Initiator  is  supported.     This  parameter  is  optionally  supported  for  an 
implementation  acting  as  a  Responder. 

10.8.8        Initiator  Identity.  Passwords  and  Account 

An  Initiator  must  be  capable  of  sending  and  not  sending  the  parameters 
<initiator  identity>,  <filestore  password>,  <access  passwords>  and 
<create  password>  to  satisfy  the  requirements  of  the  Responder. 

The  contents  of  the  <initiator  identity>,  <filestore  password>, 
<access  passwords>,  <create  password>  and  <account>  parameters  shall  be 
in  the  convention  of  the  responding  implementation. 

10.9  Range  of  Values  for  Integer-Type  Parameter 

In  addition  to  the  parameters  specified  for  FTAM  Phase  2  under  the  same 
heading,   the  parameters 

F-RECOVER  request 

bulk- transfer-number 

NBS-AS3 

NBS -Node -Name 

starting- fadu 
f adu-count 

may  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than 
eight  octets. 
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I   APPENDIX  A: 

PROFILES  REQUIREMENTS  LIST  FOR  NIST  OIW  FTAM  PHASE  3 


A.O  Introduction 

This  appendix  to  NIST  FTAM  Phase  3  Agreements  defines  a  Profile  Requirements  List  (PRL)  for  the  Implementation 
Profiles 

T1.3    -     Simple  File  Transfer 
T2.3    -     Positional  File  Transfer 
A1.3    -     Simple  File  Access 
Ml. 3   -  Management 


This  appendix  specifies  the  constraints  and  characteristics  of  NIST  OIW  FTAM  Phase  3  on  what  shall  or  may 
appear  in  the  supplier  columns  of  an  FTAM  Phase  3  PICS.  This  appendix  is  completely  based  on  ISO  8571-5.  It 
uses  only  a  selection  of  the  tables  from  ISO  8571-5  which  are  necessary  for  the  specification  of  the  FTAM  Phase  3 
status,  and  retains  their  numbering,  in  order  to  facilitate  for  a  supplier  to  fill  in  the  respective  PICS  Proforma. 

This  appendix  is  a  summary  of  all  definitions  of  FTAM  Phase  3  as  they  appear  in  the  Stable  implementation 
Agreements  for  OSI  Protocols,  Version  3  Edition  1,  December  1989,  chapters  9  and  10. 


A.0.1  Conformance  requirement  of  Base  Standards 

The  D-column  of  sections  A.I  to  A.  13  specifies  the  conformance  requirement  of  the  base  standards  ISO  8571,  as 
written  in  ISO  8571-5.  The  definitions  apply  as  defined  in  ISO  8571-5  clause  8.1  : 

m  -    mandatory  support 
o     -  optional  support 
f     -  full  support  of  attributes 
p     -  partial  support  of  attributes 
-   not  applicable 

A  single  value  in  the  D-column  applies  to  the  Initiator  role  of  a  system  as  well  as  to  the  Responder  role.  If  two 
values  are  specified  in  the  D-column  separated  by  a  space,  they  apply  to  the  Initiator  (I)  role  and  to  the  Responder 
(R)  role,  respectively. 


A.0.2  Conformance  requirement  of  Profiles 

The  Conformance  requirement  of  the  Implementation  Profiles  is  specified  in  the  'Profiles'  column/columns  in  sec- 
tions A.I  to  A. 13.  The  following  convention  is  applied  for  this  purpose  : 

0    a  'PROFILES'  column  is  valid  for  all  Profiles  T1 .3,  T2.3,  A1 .3  and  Ml  .3 

0    if  different  conformance  requirements  apply  to  different  Profiles,  separate  columns  are  included  in  the  tables,  each 
bearing  the  corresponding  Profile  name  as  its  heading,  or  separate  tables  for  these  Profiles  are  used 

o    a  single  value  in  these  columns  applies  to  the  Initiator  as  well  as  to  the  Responder  role  of  an  implementation 
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o   if  two  values  are  specified  in  a  column  separated  by  a  space,  they  apply  to  the  Initiator  (I)  role  and  to  the  Re- 
sponder  (R)  role,  respectively. 

For  the  conformance  requirements  of  the  NIST  FTAM  Phase  3  Profiles  the  following  abbreviations  are  used, 
mandatory;  m  : 

This  is  a  mandatory  or  optional  feature  in  the  base  standard.  It  shall  be  supported,  i.e.,  its  syntax  and  procedures 
shall  be  implemented  as  specified  in  the  base  standard  or  in  FTAM  Phase  3  by  all  implementations  claiming  I 
conformance  to  the  Profile. 

However,  it  is  not  a  requirement  that  the  feature  shall  be  used  in  all  instances  of  communication,  unless  mandated 
by  the  base  standard  or  stated  otherwise  in  FTAM  Phase  3. 

For  fully  supported  attributes,  this  implies  that  at  least  the  minimum  range  of  attribute  values,  as  defined  in  ISO 
8571-2,  shall  be  supported  unless  stated  otherwise  in  FTAM  Phase  3. 

Also  for  features  which  are  optional  in  the  base  standard,  conformant  implementations  shall  be  able  to  interwork 
with  other  implementations  not  supporting  this  feature. 

The  support  of  a  feature  can  be  conditional,  depending  on  the  support  of  a  class  of  features  to  which  it  belongs, 
e.g.,  an  attribute  in  an  attribute  group,  a  parameter  in  a  PDU,  a  PDU  in  a  functional  unit. 

optional;  o : 

It  is  left  to  the  implementation  as  to  whether  this  feature  is  implemented  or  not. 

If  an  attribute  group  with  a  support  level  of  'o'  is  chosen  to  be  supported,  then  all  the  attributes  in  this  group  that  are 
classified  as 'm'  shall  be  supported. 

The  support  for  PDUs  is  determined  by  the  negotiation  of  functional  units  when  the  connection  is  established. 

If  a  parameter  is  optionally  supported,  then  its  syntax  shall  be  implemented,  but  it  is  left  to  each  implementation 
whether  its  procedures  are  implemented  or  not. 

When  receiving  an  optional  parameter  which  is  not  subject  of  negotiation  and  is  not  supported  by  the  Receiver,  the 
Receiver  shall  at  least  inform  the  Sender  by  informative  diagnostic  and  interworking  shall  not  be  disrupted. 

conditional;  c  : 

This  feature  shall  be  supported  under  the  conditions  specified  in  FTAM  Phase  3.  If  these  conditions  are  not  met,  the 
feature  is  outside  the  scope  of  the  Profile. 

excluded;  x  : 

This  feature  is  excluded  from  the  Profile.  The  implementor's  answer  in  the  PICS  shall  always  be  'no', 
outside  the  scope;  i  : 

This  feature  is  outside  the  scope  of  the  Profile,  i.e.,  it  may  be  ignored,  and  will  therefore  not  be  subject  of  a  Profile 
conformance  test.  However  the  syntax  of  all  parameters  of  supported  PDUs  shall  be  implemented,  even  if  their 
procedures  are  not  (i.e.,  the  Receiver  shall  be  able  to  decode  the  PDU). 

not  applicable;  - : 

This  feature  is  not  defined  in  the  context  where  it  is  mentioned,  e.g.,  a  parameter  which  is  not  part  of  the  respective 
PDU.  The  occurrence  of  'not  applicable'  features  is  mainly  due  to  the  format  of  the  tables  in  the  Phase  3  Profiles 
Requirements  List. 
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A.I  (void) 
A.2  (void) 


Section  1 


December  1989 


Section  2:  General  ISO  8571  Detail 
A.3  ISO  8571  Protocol  versions 


FTAM  protocol  version  number(s) 

One 

A.4  ISO  8571  Addenda 

ISO  8571-1  — 

ISO  8571-2 

ISO  8571-3 

ISO  8571-4 

ISO  8571-5 

A.5  Defect  report  numbers  and  amendments 


ISO  8571-1  — 

ISO  8571-2 

ISO  8571-3  — 

ISO  8571-4 

ISO  8571-5 

A.6  Global  statement  of  conformance 


Does  FTAM  Phase  3  conform  to  ISO  8571  ?  yeS 
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A.7  Initiator  /  Responder  capability 


ROLES 

D 

PROFILES 

1  R 

1 

Sender 

0 

o  o 

2 

Receiver 

0 

o  o 

NOTE  -  See  section  9.18.1 


A.8  Application  Context  Name  details 


1      ISO  8571-4  defines  a  value  for  a  simple  transfer  mechanism.  Other  values  are  not  defined  for  FTAM  Phase  3 
(see  9.5{9)). 
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Section  3  :  Syntax  Detail 

A.9  Abstract  syntaxes 


Object  Descriptor 

Object  Identifier 

D 

T1.3 

T2.3 

A1.3 

M1.3 

FTAM  PCI 

(iso  standard  8571  abstract-syntax(2) 
ftam-pci(1) } 

m 

m 

m 

m 

m 

FTAM  FADU 

{iso  standard  8571  abstract-syntax(2) 
ftam-fadu(2) } 

0 

1 

m 

m 

i 

{joint-iso-ccitt  association-control(2) 
abstract-syntax(l)  apdus(O)  versionl(l) } 

m 

m 

m 

m 

m 

FTAM  unstructured 
text  abstract  syntax 

{iso  standard  8571  abstract-syntax(2) 
unstructured-text(3) } 

0 

m 

m 

m 

FTAM  unstructured 
binary  abstract  syntax 

{iso  standard  8571  abstract-syntax(2) 
unstructured-binary(4) } 

0 

m 

m 

m 

NBS  file  directory 
entry  abstract  syntax 

{iso  identified-organization  oiw(14)  ftamsig{5) 
abstract-syntax(2)  nbs-as2(2) } 

- 

c 

c 

c 

- 

NBS  abstract 
syntax  AS1 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-as1{1) ) 

- 

c 

c 

• 

NBS  random  access 
node  name  abstract 
syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-node-name(3) ) 

i 

c 

see  10.9 

c 

NBS  random  binary 
access  file  abstract 
syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-random-binary(4) } 

i 

c 

0 

NBS  simple  text 
abstract  syntax 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-simple-text(5) } 

i 

c 

c 

NOTES 

1  Tfie  abstract  syntaxes  wfiich  are  supported  in  ttie  Implementation  Profile  M1.3  depend  on  the  T-or  A-Profile  in  conjunction  with 
which  Ml. 3  is  implemented. 

2  The  support  requirements  for  the  conditional  abstract  syntaxes  depend  on  the  constraint  sets  and  document  types  which  are 
implemented  (see  clause  A.  13). 

3  ISO  8571  requires  the  presence  of  the  transfer  syntax  derived  from  the  "Basic  Encoding  of  a  single  ASN.1  type  "{joint-iso-ccitt 
asnl  (1)  basic-encoding  (1)}  encoding  rules  for  transfer  of  the  "FTAM  PCI"  and  the  "FTAM  FADU"  abstract  syntaxes.  Implementa- 
tion detail  of  this  transfer  syntax,  and  other  transfer  syntaxes  supported,  is  specified  in  the  PIGS  of  ISO  8823. 
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Section  4  :  Virtual  Filestore  Detail 


A.10  Virtual  filestore 

This  clause  details  the  conformance  to  the  file  model,  file  attribute  support  and  to  file  structure  support. 
A. 10.1  File  model 


FILE  MODEL 

D 

PROFILES 
R 

1 

Hierarchical 

0 

m 

Other  models  i 

A.I 0.2  Attributes 

A.1 0.2.1  Attribute  groups  , 

ATTRIBUTE  GROUP  NAME 

D 

PROFILES 

1 

Kernel 

m 

m 

2 

Storage 

0 

o 

3 

Security 

0 

o 

4 

Private 

0  . 

A.10.2.2  Attribute  values 

KERNEL  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

1 

Filename 

f 

m 

see  A. 10.2. 3 

2 

Permitted  Actions 

f 

m 

3 

Contents  Type 

f 

m 

see  A. 12.7 

KERNEL  GROUP 
(RESPONDER) 

D 

PROFILES 
R  full 

RANGE  OF  VALUES 

4 

Filename 

f 

m 

see  A.  10.2.3 

5 

Permitted  Actions 

f 

m 

6 

Contents  Type 

f 

m 

see  A.I 2.7 
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STORAGE  GROUP 
(INITIATOR) 

D 

PRORLES 
1  full 

1  lull 

RANGE  OF  VALUES 

t 
1 

m 

8 

Date  and  time  of  creation 

f 

m 

9 

File  availability 

f 

m 

10 

Future  filesize 

f 

m 

see  9.17.9 

NOTE  -  An  initiator  shall  not  partially  support  attributes 

STORAGE  GROUP 

D 

PRORLES 
R  full               P  partial 

rlMMVJC  Wl  VMI.IJCO 

11 

Storage  account 

P 

o 

0 

12 

Date  and  time  of  creation 

P 

o 

o 

13 

Date  and  time  of  last  modification 

P 

o 

0 

14 

Date  and  time  of  last  read  access 

P 

o 

0 

15 

Date  and  time  of  last  attribute  modification 

P 

o 

o 

16 

Identity  of  creator 

P 

o 

0 

17 

Identity  of  last  modifier 

P 

o 

0 

16 

Identity  of  last  reader 

P 

o 

0 

ie 

Identity  of  last  attribute  modifier 

P 

o 

0 

20 

File  availability 

P 

m 

X 

21 

Flleuze 

p 

m 

X 

see  9.17.9 

22 

Future  filesize 

P 

o 

o 

see  9.17.9 

SECURITY  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

23 

Access  control 

f 

m 

see  A  12.2 

24 

Legal  qualifications 

f 

m 

NOTE  -  An  initiator  shall  not  partially  support  attritxites 

SECURITY  GROUP 
(RESPONDER) 

D 

PRORLES 
R  full             R  partial 

RANGE  OF  VALUES 

25 

Access  control 

P 

tn  X 

see  A.  12.2.  9.9.2 

26 

Legal  qualifications 

P 

o  o 
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A.1 0.2.3  Filename  detail 


See  section  9.9.1 


A.10.3  File  Structures 
A.I  0.3.1  Constraint  sets 


CONSTRAINT  SET  NAME 

D 

T1.3 

T2.3 

A1.3 

M1.3 

Unstructured 

0 

m 

m 

m 

Sequential  Rat 

0 

m 

m 

Ordered  flat 

0 

o 

o 

Ordered  flat  with  unique  names 

0 

o 

o 

Ordered  hierarchical 

0 

1 

1 

General  hierarchical 

0 

1 

1 

General  hierarchical  with  unique  names 

0 

1 

1 

NBS  ordered  flat 

o 

o 

NBS  random  access 

o 

o 

A. 10.3. 2  File  and  filestore  actions 
A.10.3.2.1  Filestore  Actions 

Support  for  filestore  actions  is  dependent  upon  the  functional  units  implemented  (see  A.12.4  and  A.  12.5) 
A.I 0.3.2.2  File  Actions  - 


CONSTRAINT  SET 

RESPONDER 

unstructured 

ACTION 

D  T1.3 

Locate   

Read 

0  o 

Insert   

Replace 

0  o 

Extend 

0  o 

Erase 

0  1 
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CONSTRAINT  SET 

RESPONDER 

unstructured  sequential 

f  In9 

iiai 

ordered 
(tat 

ordered  fiat 
with  unique 
namea 

NBS 
ordered 
nai 

NBS 
random 
access 

ACTION 

D     T2.3         D  T2.3 

D 

T2.3 

D  T2.3 

D  T2.3 

0  T2.3 

7 

Locate 

  0  1 

0 

1 

0  I 

1 

i 

8 

Read 

O        O             0  o 

0 

o 

0  o 

o 

o 

• 

Insert 

  0  o 

0 

o 

0  o 

o 

o 

10 

Replace 

0  o   

0 

o 

0  o 

o 

o 

11 

Extend 

0 

o 

o  o 

0  o   

12 

Erase 

0         1           o  1 

0 

1 

0  ! 

1 

1 

CONSTRAINT  SET 

RESPONDER 

unstructured 

sequential 
flat 

ordered 
flat 

ordered  flat 
with  unique 
names 

NBS 
ordered 

flat 

NBS 
random 
access 

ACTION 

0  A1.3 

D  A1.3 

0 

A1.3 

D 

A1.3 

D  A1.3 

0  A1.3 

Locate 

0  o 

0 

o 

0 

o 

o 

o 

Read 

0  o 

0  o 

0 

0 

0 

o 

o 

0 

Insert 

0  o 

0 

o 

0 

o 

o 

o 

Replace 

0  o 

0 

o 

0 

o 

o 

o 

Extend 

0  o 

0 

o 

0 

o 

Erase 

0  0 

0  o 

0 

0 

0 

© 

o 

o 

NOTE  •  File  actions  are  not  defined  in  implementation  Profile  M1.3 
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A.1 0.3.2.3  Access  contexts  supported 

CONSTRAINT  SET 
RESPONOER  unstructured 

ACCESS  CONTEXT  D  T1.3 

1  US   

2  UA  0  m 

3  FS   

4  FL   

s  FA   

6  HN   

7  HA   


CONSTRAINT  SET 

RESPONDER 

unstructured  sequential 

ordered 

ordered  flat 

NBS 

NBS 

with  unique 

ordered 

random 

flat 

flat 

names 

fiat 

access 

ACCESS  CONTEXT 

D     T2.3         D  T2.3 

D  T2.3 

D  T2.3 

D  T2.3 

D  T2.3 

US 

UA 

0       m         o  m 

o  m 

o  m 

m 

m 

FS 

FL 

FA 

  0  m 

0  m 

0  m 

m 

HN 

HA 

0  o 

0  o 

o 
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CONSTRAINT  SET 

RESPONDER 

unstructured  sequential 

ordered 

ordered  flat 

NBS 

NBS 

with  unique 

ordered 

random 

flat 

flat 

names 

flat 

access 

ACCESS  CONTEXT 

D     A1.3         D  A1.3 

0  A1.3 

D  A1.3 

D  A1.3 

D  A1.3 

US   

UA 

0       m         0  m 

0  m 

o  m 

m 

m 

FS 

FL 

FA 

  o  m 

0  m 

0  m 

m 

HN 

HA 

0  o 

0  o 

o 

NOTE  -  The  supported  access  contexts  for  Impemenlatlon  Profile  M1.3  are  defined  In  the  T-  or  A-Profile  In  con|unctlon  with 
which  M1.3  is  Implemented. 


A.I  0.4  Additional  information 

( Void ) 


A.10.5  Override 


RESPONDER  OVERRIDE 

D 

PROFILES 

R 

1 

Create  failure 

0 

m 

2 

Select  old  file 

0 

m 

3 

Delete  and  recreate  with  old  attributes 

0 

o 

4 

Delete  and  create  with  new  attributes 

0 

m 

NOTE  -  The  specification  of  the  role  of  initator  is  given  in  section  5  (file  protocol  detail). 
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December  1989 


A.11  File  protocol 

See  sections  9.5(1)  -  (3),  9.17 

Clauses  A.1 1.2  to  A.  1 1.24  specify  an  indication  of  which  PDUs  are  supported.  The  conformance  requirements  for  PDUs 
are  dependent  on  the  particular  functional  units  implemented.  PDUs  indicated  in  clauses  A.1 1.8  to  A.1 1.24  as  conditio- 
nal shall  be  considered  as  mandatory  when  a  particular  functional  unit  is  implemented,  according  to  the  foltowing  table. 


 1 

pni  k 

1  

Functional  Units 

Ker- 
nel 

Read 

Write 

Ac- 
cess 

LFM 

EFM 

Grou- 
ping 

Reco- 
very 

Re- 
start 

F-CREATE 

A.1 1.8 

m 

F-DELETE 

A.1 1.9 

m 

F-READ-ATTRIB 

A.11.10 

m 

F-CHANGE-ATTRIB 

A.11. 11 

m 

F-OPEN 

A.11. 12 

m 

m 

F-CLOSE 

A.11. 13 

m 

m 

F-BEGIN-GROUP 

A.11. 14 

m 

F-END-GROUP 

A.11. 15 

m 

F-RECOVER 

A.11. 16 

m 

F-LOCATE 

A.11. 17 

m 

F-ERASE 

A.11. 18 

m 

F-READ 

A.11. 19 

m 

F-WRITE 

A.1 1.20 

m 

F-DATA-END 

A.1 1.21 

m 

m 

F-TRANSFER-END 

A.1 1.22 

m 

m 

F-CANCEL 

A.1 1.23 

m 

m 

F-RESTART 

A.1 1.24 

m 

NOTES 

1  in  order  to  keep  the  protocol  tables  compact  some  forward  references  have  been  introduced  to  clauses  which  expand  upon  the 

detail  of  field  support. 

2  The  FTAM  protocol  will  require  a  number  of  optional  lower  layer  service  to  be  availat)te  (eg  Application  Entity  Titles  in  ACSE).  This 
requirement  is  outside  the  scope  of  this  Profiles  Requirements  List. 
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A.11.1  GraphlcString  support  December  1989 


(Void) 

A. 11.2  FTAM  regime  establishment 


1 

D 

R 

PRORLES 
1  R 

1 

F-JNITlALiZE  PDU 

m 

m 

m  m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

State  result 

- 

m 

m 

all  values  defined  in  ISO  8571 

3 

Action  result 

- 

m 

m 

aJI  values  defined  in  ISO  8571 

4 

Protocol  version 

m 

m 

m  m 

see  Section  2 

5 

Implementation  information 

0 

0 

o  o 

see  A.12.1 

6 

Presentation  context  management 

m 

m 

m  m 

see  note  1,  9.17.10 

7 

Service  dass 

m 

m 

m  m 

see  A.  12.4 

• 

Functional  units 

m 

m 

m  m 

see  A.12.5 

9 

Atoibute  groups 

m 

m 

m  m 

see  A.  10.2 

10 

Shared  ASE  information 

0 

0 

i  i 

see  9.5(8) 

11 

FTAM  Quality  of  Service 

m 

m 

m  m 

see  A.  12.8 

12 

Contents  type  list 

0 

0 

m  m 

see  A.12.7.1.  9.18.4 

13 

Initiator  identity 

0 

m 

see  9.16.1.  9.18.4.  10.8.8 

14 

Account 

0 

o 

see  9.18.4.  10.8.8 

15 

Filestore  password 

0 

m 

see  A.12.11,  9.16.1.  10  8.8 

16 

Diagnostic 

0 

m 

see  A,  12.6,  9.13,  10.8.5.2 

17 

Checkpoint  window 

m 

m 

m  m 

see  note  2,  10.8.5.2 

NOTES 

1  The  values  available  for  the  presentation  context  management  field  depend  upon  the  functional  units  implemented  in  ISO  8823. 

2  Checkpoint  window  field  is  indicated  as  mandatory  in  accordana^ith  ISO  8571-4.  The  field  is  defaulted  to  the  value  1 
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A.11.3  FTAM  regime  termination  (orderly) 


D 
1  R 

PROFILES 
1  R 

t 

F-TERMINATE  PDU 

m  m 

m  m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Shared  ASE  information 

0  0 

1  1 

see  9.5  (8) 

3 

Charging 

-  0 

o 

see  A.12.10 

A.1 1.4  FTAM  regime  termination  (abrupt)  by  service  user 


D 

PROFILES 

1 

F-U-ABORT  PDU 

m 

m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

3 

Diagnostic 

0 

m 

see  A.12.6.  9.13 

A.11.5  FTAM  regime  termination  (abrupt)  by  service  provider 


D 

PRORLES 

1 

F-P-ABORT  PDU 

m 

m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

3 

Diagnostic 

0 

m 

see  A.12.6.  9.13.  10.8.5.2 
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A.1 1.6  File  selection 


D 
1  R 

PROFILES 
1  R 

F-SELECT  POU 

m  m 

m  m 

RANGE  OF  VALUES 

rIcLD  NAME 

OR  REFERENCE 

State  result 

m 

m 

ail  values  defined  in  lau  oo/i 

Action  result 

m 

m 

all  values  defined  in  li>0  857 1 

Attributes 

m  m 

m  m 

see  A.10.2,  9.17.9 

Requested  access 

m 

m 

see  A.12.16 

Access  passwords 

o 

m 

see  9.16  2.  10.8.8 

Concurrency  control 

0 

m 

see  A.12.13.  10.8  6.1 

Shared  ASE  information 

0  0 

i  1 

see  9.5(8) 

Account 

0 

o 

see  9.18.4,  10.8.8 

Diagnostic 

0 

m 

see  A.12.6,  9.13 

A. 11. 7  File  deselection 

D 
1  R 

PROFILES 
1  R 

F-DESELECT  PDU 

m  m 

m  m 

RANGE  OF  VALUES 

FIELDNAME 

OR  REFERENCE 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

Chargir>g 

0 

-  o 

see  A.12.10 

Shared  ASE  information 

0  0 

1  1 

see  9.5(8) 

Diagnostic 

0 

•  m 

see  A.12.6.  9.13 
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A.1 1.8  File  creation 


n 
1  R 

rrHJrlUCo 
1  R 

1 

F-CREATE  PDU 

c  c 

c  c 

see  A.11.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

State  result 

m 

-  m 

all  values  defined  in  ISO  857 

Action  result 

-  m 

•  m 

all  values  defined  in  ISO  8571 

Override 

m  - 

m 

see  A.12.15 

Initial  attributes 

m  m 

m  m 

see  A.10.2.  9.10.2.2.  9.17.9 

Create  password 

0 

m 

see  A.12.12.  9.16.2,  10.8.7  10  8.8 

Requested  access 

m 

tn  - 

see  A.12.16 

Access  passwords 

0 

m  - 

see  9.16.2.  10.8.8 

Concurrency  control 

0 

m 

see  A.12.13.  10.8.6.1 

10 

Shared  ASE  information 

0  0 

i  1 

see  9.5(8) 

11 

Account 

0 

o  - 

see  9.18.4,  10.8.8 

12 

Diagnostic 

0 

m 

see  A.  12.6,  9.13 

A.1 1.9  File  deletion 


D 
1  R 

PRORLES 
1  R 

1 

F-DELETE  PDU 

c  c 

c  c 

see  A  ll,  A.12.5 

FIELDNAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

-  m 

•  m 

all  values  defined  in  ISO  857 

3 

Shared  ASE  information 

0  0 

i  1 

4 

Charging 

-  0 

-  o 

see  A.12.10 

S 

Diagnostic 

-  0 

•  m 

see  A.12.6.  9.13 
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A.1 1.10  Read  attributes 


D 
1  R 

PRORLES 
1  R 

1 

F-READ-ATTRIB  PDU 

c  c 

c  c 

see  A.11.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

-  m 

-  m 

all  values  defined  in  ISO  8571 

3 

Attribute  names 

m 

m 

4 

Attributes 

-  0 

m 

see  A.10.2.  9.17.9 

S 

Diagnostic 

-  0 

•  m 

see  A12.6.  9.13 

A.1 1 .1 1  Change  attributes 


D 
1  R 

T1.3,  T2.3,  A1.3 

M1.3 
1  R 

1 

F-CHANGE-ATTRIB 

c  c 

1 

m  m 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

-  m 

1 

-  m 

all  values  defined  in  ISO  8571 

3 

Attributes 

fn  0 

i 

m  m 

see  A.10.2.  9.17  9 

4 

Diagnostic 

-  0 

i 

-  m 

see  A.12  6,  9.13 

A. 11. 12  File  open 


D 
1  R 

T1.3,  T2.3,  A1.3 
1  R 

M1.3 

F-OPEN  PDU 

c  c 

m  m 

1 

see  A.11,  A.12.5 

FIELDNAME 

RANGE  OF  VALUES 
OR  REFERENCE 

State  result 

-  m 

m 

all  values  defined  in  ISO  8571 

Action  result 

m 

•  m 

all  values  defined  in  ISO  8571 

Processing  mode 

m  - 

m  - 

see  A.12.17 

Contents  type 

m  m 

m  m 

see  A. 12.7.2 

Concurrency  control 

0  0 

m  o 

se«  A.12.13.  10.8.6.1 

Shared  ASE  information 

0  0 

1  1 

see  9.5(3) 
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• 

EnaWe  FADU  locking 

m  - 

m  • 

1  falseforTl.aandTa.a 

9 

Activity  identifief 

0  - 

o 

10 

Diagnostic 

-  0 

m 

1                   see  A.  12.6.  9.13 

11 

Recovery  mode 

m  m 

m  m 

1                   see  A.  12.18 

12 

Remove  contexts 

0  - 

1  . 

13 

Define  contexts 

0  - 

1  - 

14 

Presentation  action 

m 

m 

1                   see  notes 

NOTES 

1  The  values  available  for  the  presentation  action  field  depend  upon  the  fur>ctional  units  implemented  in  ISO  8823. 

2  Presentation  action  field  is  indicated  as  mandatory  in  accordance  with  ISO  8571-4.  The  field  is  defaulted  to  no  action. 


A.11.13  File  Close 


D 

T1.3,  T2.3,  A1.3 

M1.3 

1 

F-CLOSE  PDU 

c 

m 

i 

see  A  ll.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

m 

m 

1 

all  values  defined  in  ISO  8571 

3 

Shared  ASE  information 

0 

1 

1 

see  9.5(8) 

4 

Diagnostic 

0 

m 

1 

see  A.12.6.  9.13 

A. 11. 14  Beginning  of  grouping 


D 
1  R 

PROFILES 
1  R 

1 

F-BEGIN-GROUP  PDU 

c  c 

c  c 

see  A  ll.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Threshold 

m  - 

m 

A.11.15  End  of  grouping 


D  PROFILES 

F-END-GROUP  PDU 

c  c 

see  A  ll.  A. 12.5 

The  F-ENO-GROUP  PDU  carries  no  fields. 
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A.11.16  Regime  recovery 

December  1989 

D 

T1.3,  T2.3,  A1.3           Ml. 3 

1  R 

i  R 

1 

F-RECOVER  PDU 

c  c 

c  c  i 

see  A.11.  A.12  5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

State  result 

-  m 

-    m  I 

all  values  defined  in  ISO  8571 

3 

Action  result 

-  m 

-    m  1 

aJI  values  defined  in  ISO  8571 

4 

Activity  identifier 

m  - 

m    -  1 

S 

Bulk  transfer  number 

m  - 

m    -  i 

see  10.9 

e 

Requested  access 

m  - 

m    -  1 

see  A.I  2. 16 

7 

Access  passwords 

0  - 

m    •  1 

see  9.16.2,  10.8.8 

a 

Contents  type 

-  m 

-    m  1 

see  A.12.7.2 

9 

Recovery  point 

m  m 

m    m  1 

10 

Diagnostic 

-  0 

-    m  1 

see  A.12  6.  9.13,  10.8.5.2 

11 

Remove  contexts 

0  - 

1    •  1 

see  notes 

12 

Define  contexts 

0  - 

1    •  1 

see  notes 

13 

Presentation  action 

-  m 

m  I 

see  notes 

NOTES 

1  The  values  available  for  the  presentation  action  field  depend  upon  the  functional  units  implemented  in  ISO  8823. 

2  Presentation  action  field  is  indicated  as  mandatory  in  accordance  with  ISO  8571-4.  The  field  is  defaulted  to  no  action. 


A.11. 17  Locate  file  access  data  unit 


D       T1.3,  T2.3 
1  R 

A1.3 
1  R 

Ml. 3 

1 

F-LOCATE  PDU 

c      c  1 

m  m 

1 

see  A  ll.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result 

-    m  1 

-  m 

1 

all  values  defined  in  ISO  8571 

3 

FADU  idenbt>' 

m    0  1 

m  o 

1 

see  9.17.9 

4 

FADU  lock 

0    -  1 

o  - 

1 

see  A.12.14 

5 

Diagnostic 

-     0  1 

-  m 

1 

see  A.12.6,  9.13 

10-33 


December  1989 


A.11.18  Erase  file  access  data  unit 


D       T1.3,  T2.3  A1.3  M1.3 

I    R  I  R 


F-ERASE  PDU 

c     c  1 

m    m  1 

see  A.11.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

-    m  1 

-    m  1 

all  values  defined  in  ISO  8571 

FADU  identity 

m    -  1 

m    •  1 

see  9.17.9 

Diagnostic 

-     0  1 

•    m  i 

see  A.12.6.  9.13 

A. 11. 19  Read  bulk  data 


D 
1  R 

T1.3,  T2.3 
1  R 

A1.3 
t  R 

M1.3 

F-READ  PDU 

c  c 

c  c 

m  m 

1 

see  A.11,  A.12.5 

FIELDNAME 

RANGE  OF  VALUES 
OR  REFERENCE 

FADU  idenbty 

m 

m  - 

m 

1 

see  9.17.9 

Access  context 

m 

m 

m 

1 

see  A.  10.3.2.3 

FADU  lock 

0 

1 

0 

1 

A.1 1.20  Write  bulk  data 


D 
1  R 

T1.3,  T2.3 
1  R 

A1.3 
1  R 

M1.3 

F-WRITE  PDU 

c  c 

c  c 

m  m 

see  A  ll,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

FADU  operation 

m  - 

m  • 

m  - 

1 

FADU  identity 

m  - 

m  - 

m  - 

1 

see  9.17.9 

FADU  Lock 

0  - 

1 

o 

1 
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A.1 1 .21  End  of  data  transfer 


D             T1.3,  T2.3,  A1.3           Ml. 3 

F-DATA-END  PDU 

c 

m  1 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

m  1 

all  values  defined  in  ISO  8571 

Diagnostic 

0 

m  1 

see  A.12.6,  9.13 

A.1 1,22  End  of  transfer 

1 

D 

R 

T1.3,  T2.3,  A1.3           Ml. 3 
1  R 

F-TRANSFER-END  PDU 

c 

c 

m    m  1 

see  A  ll.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

-    m  1 

all  values  defined  in  ISO  8571 

Shared  ASE  information 

0 

0 

i    1  i 

see  9.5{8) 

Diagnostic 

0 

-   m  1 

see  A.12.6,  9.13 

A.1 1 .23  Cancel  data  transfer 

See  section  9.11 

D             T1.3,  T2.3,  A1.3           Ml. 3 

F-CANCEL  PDU 

c 

m  i 

see  A.11,  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Action  result 

m 

m  1 

all  values  defined  in  ISO  8571 

Shared  ASE  information 

0 

i  i 

see  9.5(8) 

Diagnostic 

0 

m  i 

see  A.12.6.  9.13 

A.1 1 .23.1  F-CANCEL  mapping 

See  sections  9.11,  9.17.10 
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A.1 1 .24  Restart  data  transfer 


D            T1.3,  T2.3,  A1.3           Ml. 3 

1 

F-RESTARTPDU                       c                      c  S 

see  A  ll.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Checkpoint  tdentifier                     m                      m  1 

A.1 2  Expanded  PDU  field  and  filestore  detail 

This  clause  identifies  further  PDU  field  and  filestore  detail  to  expand  on  that  given  in  A.  10  and  A.11. 

A.1 2.1  Implementation  information  detail 

See  sections  9.5(6),  9.12, 10.8.3 

A.1 2.2  Access  control  detail 

See  sections  9.9.2, 10.7.3 

Access  control  element  terms 

D  PROFILES 

RANGE  OF  VALUES 

1 

Action  list                                  m  m 

2 

Concurrency  access                     o  o 

see  A. 12  3,3 

3 

Identity                                     o  o 

4 

Passwords                                o  o 

see  A  12  3  5,  A.12  3  6.  10.8  8 

5 

Location                                 o  o 

A.1 2.3  Access  control  element  detail 
A.1 2.3.1  Action  list  detail  (InKlator) 

( Void ) 


A.1 2.3.2  Action  list  detail  (responder) 


{ Void ) 
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A.1 2.3.3  Concurrency  access  term 

If  the  concurrency  access  term  is  supported  in  the  access  control  element  the  following  details  of  the  concurrency 
control  shall  be  available  with  each  action. 


T1  T 

Action 

not  required 
D  T1.3 

shared 
D 

T1.3 

exclusive 
D  T1J 

no  access 
D  T1.3 

1 

Read 

0 

0 

0 

o 

0 

o 

o  o 

2 

Insert 

0 

1 

0 

1 

0 

1 

o  1 

3 

Replace 

0 

0 

0 

o 

0 

o 

o  o 

4 

Extend 

0 

0 

0 

o 

0 

o 

0  o 

5 

Erase 

0 

1 

0 

1 

0 

1 

0  i 

6 

Read  attributes 

0 

0 

0 

o 

0 

o 

o  o 

7 

Change  attributes 

0 

1 

0 

1 

0 

1 

0  1 

a 

Delete  file 

0 

0 

0 

o 

0 

o 

0  o 

T2.3 
Action 

not  required 
D  T2.3 

shared 
D 

T2.3 

exclusive 
D  T2.3 

no  access 
D  T2.3 

9 

Read 

0 

0 

0 

o 

0 

0 

o 

o 

10 

Insert 

0 

0 

0 

o 

0 

o 

0 

o 

11 

Replace 

0 

0 

0 

o 

0 

o 

0 

o 

12 

Extend 

0 

o 

0 

o 

0 

o 

0 

0 

13 

Erase 

0 

1 

0 

i 

0 

i 

0 

1 

14 

Read  attributes 

0 

o 

0 

o 

0 

o 

0 

o 

IS 

Change  attributes 

0 

1 

0 

1 

0 

1 

0 

1 

16 

Delete  file 

0 

0 

0 

o 

0 

o 

0 

o 
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A1.3 

Action 

not  required 
D  A1.3 

shsrsd 
D 

A1.3 

exclusive 
D  A1.3 

no  access 
D  A1.3 

17 

Read 

0 

0 

0 

o 

0 

o 

0 

o 

18 

Insert 

0 

0 

0 

o 

0 

o 

0 

o 

19 

Replace 

0 

o 

0 

o 

o 

o 

0 

o 

20 

Extend 

0 

o 

0 

o 

0 

o 

0 

o 

21 

Erase 

0 

0 

0 

o 

0 

o 

0 

o 

22 

Read  attributes 

0 

Q 

o 

o 

0 

o 

0 

o 

23 

Change  attributes 

0 

1 

0 

1 

0 

1 

0 

1 

24 

Delete  file 

o 

o 

0 

o 

o 

o 

0 

o 

Ml. 3              not  required 
Action  D 

M1.3 

shared 

D 

M1.3 

exclusive 
D 

no  access 
M1.3  D 

Ml. 3 

25 

Read 

0 

0 

1 

0 

0 

26 

Insert 

0 

0 

I 

o 

0 

27 

Replace 

0 

0 

0 

0 

2B 

Extend 

0 

0 

0 

o 

29 

Erase 

0 

0 

0 

0 

30 

Read  attributes 

0 

0 

0 

o 

0 

o 

0 

o 

31 

Change  attributes 

0 

0 

0 

o 

0 

o 

o 

o 

32 

Delete  file 

0 

0 

0 

o 

o 

o 

c 

o 

A.1 2.3.4  Identity  term 

(  Void  ) 


A.1 2.3.5  Initiator  access  passwords 

If  the  passwords  term  of  the  access  control  element  is  implemented  the  foltowing  values  shall  be  supported  for  the 
initiator  role. 


See  section  9.16.3 


Initiator  Access  Passwords 

D 

PROFILES 
1 

1 

OctetString 

0 

o 

2 

GraphicString 

0 

o 
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A.1 2.3.6  Responder  access  passwords 

If  the  passwords  term  of  the  access  control  element  is  implemented  the  following  values  shall  be  supported  for  the 
responder  role. 


See  section  9.16.3 


Responder  Access 
Passwords 

D 

T1.3 
OctetStrIng 
GraphlcStrlng 

T2.3 
OctetStrIng 
GraphlcStrlng 

A1.3 
OctetStrIng 
GraphlcStrlng 

Ml. 3 
OctetStrIng 
GraphlcStrlng 

Read-passwofd 

0 

o 

o 

o 

1 

Insert-password 

0 

1 

o 

0 

1 

Replace -pas  sword 

0 

o 

o 

0 

1 

Ertend-password 

0 

o 

o 

0 

1 

Erase-password 

0 

1 

I 

0 

i 

Read-attribute-password 

0 

o 

o 

0 

o 

Chang  e-anribcite-password 

0 

i 

i 

1 

o 

Delete-password 

0 

0 

o 

0 

o 

A.I  2.3.7  Location  term 

( Void ) 

A.1 2.3.7.1  Application  Entity  Titles  detail 

See  section  9.5(7) 


A.12.3.8  Access  control  element  combinations 


Combinations 

D 

PROFILES 
R 

Identity 

Password 

Location 

0 

0 

Identity 

Password 

0 

0 

Identity 

Location 

0 

o 

Password 

Location 

0 

o 

Identity 

0 

o 

Password 

0 

0 

Location 

0 

0 

NOTE  -  Implementation  of  access  control  without  any  of  the  above  combinations  is  valid. 
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A.12.4  Service  class  field  detail 

Se«  table  9.7  and  sections  10.5.1, 10.8.1 

D          T1.3,  T2.3          A1.3  Ml.3(T) 

Ml. 3  (A) 

Transfer  dass 

0              m                 1  m 

1 

Access  dass 

o               1                  m  1 

m 

Management  dass 

oil  m 

m 

Transfer  and  management  dass 

0              o                  1  m 

1 

Unconstrained  dass 

u                I                  i  1 

NOTES 

1  The  initiator  is  only  permitled  to  specify  those  oomt>inations  defined  in  ISO  8571-3 

2  The  notation  M1.3(T)  Indicates  M1.3  combined  with  a  Transfer  Profile  T1.3  or  T2.3.  M1.3<A}  means  M1.3  combined  with  the 
Access  Profile  A1.3. 

A.12.5  Functional  unit  field  detail 

See  table  9.7  and  sections  10.8,1, 10.8.2 

11. 3,  T2.3 

FUNCTIONAL  UNITS 

SERVICE  CLASSES 
Transfer                   Transfer  and  Management 
D        T1.3,  T2.3                  D        T1.3,  T2.3 

1 

Kernel 

m               m                       m  m 

2 

Read  (see  note  2) 

CO  CO 

i 

Write  (see  note  2) 

CO  CO 

4 

File  Access     

i 

Limited  File 
Management 

0                o  mm 

6 

Enhanced 

File  Management 

0               1                        0  i 

7 

Grouping 

mm  mm 

S 

FAOU  Locking  

9 

Recovery 

0                   O                              0  o 

10 

Restart 

0                     O  CO 

NOTES 

1  the  recovery  and  the  restart  functional  units  are  only  available  at  the  interna!  file  service  interface  and  should  only  be  explicitly 
referenced  in  the  protocol. 

2  the  c  indicates  that  either  or  both  of  the  read  and  write  functional  units  shall  be  implemented  in  the  particular  service  class. 
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A1.3 

FUNCTIONAL  UNITS 

SERVICE  CLASSES 
Access 
D  A1.3 

11 

Keme) 

m 

m 

12 

Read 

m 

m 

13 

Write 

m 

m 

14 

File  Access 

m 

m 

IS 

Limited  RIe 

Management 

0 

o 

^■ 

Flic  li?.T\3o^. 

c 

I 

17 

Grouping 

0 

o 

18 

FADU  Locking 

0 

o 

see  10.8.6.2 

19 

Recovery 

0 

o 

20 

Restart 

0 

o 

See  10.8.1 


M1.3(T) 

SERVICE  CLASSES 

Transfer  Management 

Transfer  and  Management 

FUNCTIONAL  UNITS 

D      M1.3(T)       D  M1.3(T) 

D 

M1.3(T) 

21 

Kernel 

m  m 

m 

m 

22 

Read 

c 

o 

23 

Write 

c 

0 

24 

nie  Access     

25 

Limited  RIe 

Management 

0       m  mm 

m 

m 

26 

Enhanced 

File  Management 

0       m               0  m 

o 

m 

27 

Grouping 

m  m 

m 

m 

28 

FADU  Locking     

2S 

Recovery 

0 

o 

30 

Restart 

0 

o 

NOTE  -  M1.3(T)  indicates  Ml  .3  in  conjunction  with  a  Transfer  Profile  T1.3  or  T2.3.  This  taWe  fists  only  the  addtionsl  furvctionalitv-  as 
defined  by  Ml. 3. 
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Ml. 3(A) 


FUNCTIONAL  UNITS 


S««  10.8.1 
SERVICE  CLASSES 


Acxiess 

D       Ml. 3(A) 


Management 
D      Ml. 3(A) 


Kernel 


3S 


37 


39 


Read 


Write 


File  Access 


Limited  Rle 
Management 


Enhanced 

File  Management 


m 


Grouping 


FADU  Locking 


Recovery 


Restart 


NOTE  -  M1.3{A)  indicates  Ml  3  in  conjunction  with  the  Access  Profile  A1.3.  This  table  lists  only  the  additional  functionality  as  defined 
by  M1.3. 


A.12.6  Diagnostic  field  detail 


D 

T1.3,  T2.3,  A1.3 

M1.3 

Diagnostic  type 

m 

m 

m 

Error  identifier 

m 

m 

m 

Error  observer 

m 

m 

m 

Error  source 

m 

m 

m 

Suggested  delay 

o 

c 

1        see  10.8.5.2 

Further  details 

0 

m 

m 

For  values  of  the  'further  details'  term  only  the  support  of  character  strings  of  th«  ISO  646,  IRV  (GO)  and  ISO  8859-1 
(GO  and  G1)  character  sets  Is  required  (see  sec.  y.l3j. 
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A.I  2.7.1  Contents  type  list  parameter 

  See  section  9.10.2,1   


D 

PROFILES 
1  R 

Maximum  number  of  elements 

document  type  specifications 
abstract  syntax  specifications 

0 
0 

o  m 
o  m 

A.I  2.7.2  Contents  type  parameter 

See  section  9.10.2.3 

D 

PROFILES 

REFERENCE 

document  type  specifications 

0 

m 

see  9.9.1 

abstract  syntax  /  constraint  set  pair 
specifications 

0 

1 

NOTE  -  The  detail  of  document  types  supported  is  contained  in  dause  A.  13. 


A.12.8  FTAM  Quality  of  service  details 


See  section  10.8.5.2 


A.I 2.9  Details  of  shared  ASE  Information 

( Void ) 


A.I  2.10  Details  of  charging 

 See  section  9.5(8),  9.18.4 


Charging 

D 

PROFILES 

R 

Resource  identifier  term 

m 

m 

Charging  unit  term 

m 

m 

Charging  value  term 

m 

m 
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A.I  2.1 1  Filestore  password  detail 


Filestore  password  detail 

D 

PROFILES 

OctetString 

o 

o 

GraphicString 

0 

o 

A.I  2.1 2  Create  password  detail 

See  section  9.16.3 

Create  password  detail 

D 

PROFILES 

OctetString 

o 

o 

GraphicString 

0 

o 

A.12.13  Concurrency  control 
A.12.13.1  Supported  values 

See  section  10.8.6.1 


T1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

T1.3 

D 

T1.3 

0 

T1.3 

D 

T1.3 

Read 

0 

o 

0 

o 

0 

o 

0 

o 

Insert 

0 

1 

0 

1 

0 

1 

o 

1 

Replace 

0 

o 

0 

o 

o 

o 

0 

o 

Extend 

0 

o 

0 

o 

0 

0 

o 

o 

Erase 

0 

1 

0 

1 

0 

1 

o 

1 

Read  attrib 

0 

o 

0 

o 

0 

o 

0 

o 

Change  attrib 

0 

i 

0 

1 

0 

1 

0 

I 

Delete  file 

0 

o 

0 

o 

0 

o 

0 

o 
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T2.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

T2.3 

D 

T2.3 

D 

T2.3 

D  T2.3 

« 

Read 

0 

0 

0 

o 

0 

o 

0  o 

10 

Insert 

0 

o 

o 

o 

0 

o 

o  o 

11 

Replace 

0 

o 

0 

o 

o 

o 

0  o 

12 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

13 

Erase 

0 

1 

o 

1 

0 

1 

0  1 

14 

Read  attrib 

0 

o 

o 

o 

0 

o 

0  o 

25 

Change  attrib 

0 

i 

0 

1 

0 

1 

0  1 

16 

Delete  file 

0 

0 

0 

o 

0 

o 

0  o 

A1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

A1.3 

D 

A1.3 

D 

A1.3 

D 

A1.3 

17 

Read 

0 

o 

0 

o 

0 

o 

o 

0 

18 

Insert 

0 

0 

0 

o 

0 

0 

0 

o 

IS 

Replace 

0 

o 

0 

o 

0 

o 

0 

o 

20 

Extend 

0 

0 

0 

o 

0 

o 

0 

o 

21 

Erase 

0 

0 

0 

o 

0 

o 

0 

o 

22 

Read  attrib 

0 

0 

0 

o 

0 

o 

0 

o 

23 

Change  attrib 

0 

I 

0 

1 

0 

1 

0 

1 

24 

Delete  file 

0 

o 

0 

o 

0 

0 

0 

o 
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M1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

M1.3 

D 

M1.3 

D 

M1.3 

D  M1.3 

25 

Read 

0 

0 

o 

o  1 

26 

Insert 

0 

o 

o 

0  1 

27 

Replace 

0 

o 

• 

0 

o  1 

2S 

Extend 

0 

o 

o 

o  i 

29 

Erase 

o 

0 

0 

o  1 

30 

Read  attrib 

0 

o 

0 

o 

0 

o 

0  o 

31 

Change  attrib 

0 

o 

0 

o 

0 

o 

0  o 

32 

Delete  file 

0 

o 

o 

o 

0 

o 

0  o 

A.12.13.2  Responder  Default  values 


See  sections  9.14, 10.8.6.1 


A.12.14  FADU  Locking 


A1.3 

not  required 

FADU  Locking  Support  Values 
shared 

exclusive 

no  access 

D 

A1.3 

D 

A1.3 

D 

A1.3 

D  A1.3 

Read 

0 

o 

0 

o 

0 

o 

0  o 

Insert 

0 

o 

0 

o 

0 

o 

0  o 

Replace 

0 

o 

0 

0 

0 

o 

0  o 

Extend 

0 

o 

o 

o 

0 

o 

0  o 

Erase 

0 

o 

o 

o 

0 

o 

0  o 
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A.1 2.1 5  Initiator  Override 


Initiator  override  D 

PROFILES 
1 

1 

Create  failure  o 

o 

2 

Select  old  file  o 

o 

3 

Delete  and  recreate  with  old  attributes  o 

o 

4 

Delete  and  create  with  new  attributes  o 

o 

NOTE  -  The  specification  of  the  role  of  resporxJer  is  given  in  the  filestore  section 

A.I  2.1 6  Requested  Access 

See  section  9.15 

Action  D 

T1.3  T2.3 

A1.3 

M1.3 

Read  o 

o  o 

o 

Insert  o 

1  o 

o 

Replace  o 

0  o 

o 

, 

Extend  o 

0  o 

0 

Erase  o 

X  X 

0 

Read  attribute  o 

0  o 

0 

m 

Change  attribute  o 

1  1 

1 

m 

Delete  file  o 

o  o 

0 

m 

A.12.17  Processing  mode 

Processing  mode  D 

T1.3  T2.3 

A1.3 

M1.3 

Read  o 

o  o 

o 

Insert  o 

1  o 

o 

Replace  o 

o  o 

o 

Extend  o 

o  o 

o 

Erase  o 

X  X 

o 
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A.12.18  Recovery  mode 

See  section  10.8.5.2 


Recovery  mode 

D 

T1.3,  T2.3,  A1.3 

M1.3 

None 

o 

m 

1 

At  start  of  transfer 

0 

m 

1 

Any  active  cfieckpoint 

0 

o 

i 
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Section  6  :  Document  Type  Detail 

A.13  Document  types 

See  section  10.7.1 

Conformance  to  document  types  is  given  at  two  levels.  The  following  table  indicates  which  document  types  have 
some  level  of  support.  The  detail  of  that  level  of  support  is  stated  in  the  following  tables. 


Entry  number 

FTAM-1  D 

11 .3      T2.3      A1.3   Ml. 3 

Object  descriptor 

ISO  FTAM  unstructured  text  o 

m          m          m  i 

Object  identifier 

{iso  standard  8571  document-type(5)  unstructured-text(l)} 

see  A.  13.1 

Entry  number 

FTAM-2  D 

11 .3      T2.3      A1.3    Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  sequential  text  o 
{iso  standard  8571  document-type(5)  sequential-text(2)} 

i           m          m  i 

see  A.  13.2 

Entry  number 

FTAM-3  D 

T1.3      T2.3      A1.3    Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  unstructured  binary  o 
{iso  standard  8571  document-type(5)  unstructured-binary(3)} 

m          m          m  i 

see  A.  13.3 

Entry  number      FTAM-4  D         T1.3      T2.3      A1.3   Ml. 3 

Object  descriptor    ISO  FTAM  sequential  binary  o  i  o  o  i 

Object  identifier     {iso  standard  8571  document-type(5)  sequential-binary(4)}  see  A.  13.4 


Entry  number 

NBS-6 

D 

T1.3      T2.3      A1.3    Ml. 3 

Object  descriptor 

NBS-6  FTAM  sequential  file 

i           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  sequential(6) } 

see  A.  13.5 

Entry  number 

NBS-7 

D 

T1.3      T2.3      A1.3    Ml. 3 

Object  descriptor 

NBS-7  FTAM  random  access  file 

i           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

docunnent-type(5)  random-file(7) } 

see  A.  13.6 
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Entry  number 

NBS-8 

D 

T1.3      T2.3      A1.3  M1.3 

Object  descriptor 

NBS-8  FTAM  indexed  file 

i           o          o  j 

Object  identifier 

{iso  identified-organization  oiw{14)  ftamsig(5) 

document-type(5)  indexed-file(8) } 

see  A.  13.7 

Entry  number 

NBS-9 

D 

T1.3      T2.3      A1.3   Ml. 3 

Object  descriptor 

NBS-9  FTAM  file  directory  file 

o           o           o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  file-directory(9) } 

see  9.18.3 

Entry  number 

NBS-10 

D 

T1.3      T2.3      A1.3   Ml. 3 

9 

Object  descriptor 

NBS-10  FTAM  random  binary  access  file 

j           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  random-binary(IO)  } 

see  10.7.1 

j  Entry  number 

NBS-11 

D 

T1.3      T2.3      A1.3  M1.3 

Object  descriptor 
Object  identifier 

NBS-1 1  FTAM  indexed  file  with  unique  keys 
{iso  identified-organization  oiw(14)  ftamsig(5) 
document-type(5)  indexed-file-with-unique-keys(ll) } 

i            o           o  i 
see  A.  13.8 

Entry  number 

NBS-1 2 

D 

T1.3      T2.3      A1.3  IVII.S 

Object  descriptor 
Object  identifier 

NBS-1 2  NBS  FTAM  simple  text  file 
{iso  identified-organization  oiw(14)  ftamsig(5) 
document-type(5)  simple-text-file(12)  } 

i           o          o  i 

see  A.  13.9 
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Constraint  sets  and  FADU  Identities  for  document  types 


For  the  constraint  set  /  FADU  identity  tables  the  following  notation  is  used: 


mandatory 


optionai 
not  supported 
not  applicable 
excluded 


In  the  constraint  set  definition,  or  optional  in  the  constraint  set  definition  but  shall  be  implemented  by  implementations 
claiming  conformance  to  the  Profile.  The  support  of  the  FADU  identity  will  be  dependent  on  the  actions  which  have  been 
implemented. 

in  the  constraint  set  definition 

(outside  the  scope  of  this  ISP,  may  be  ignored) 

(not  defined  in  ttie  constraint  set  definition) 

(disallowed  in  the  document  type  definition  or  in  FTAM  Phase  3) 


Implementation  Profile  T1.3. 


^^^^^^^    FADU  Identity 
Constraint  Set  ^'^'^x^,^^ 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM-1 

m 

FTAM-3 

m 

NBS-9 

m 
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Implementation  Profile  T2.3  (see  sees.  9.10,  10.7.2) 


^^^^     FADU  Wenlity 
Constraint  S€t  ^^^^ 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM  - 1 

m 

FTAM  -  3 

m 

NBS-9 

m 

FTAM  sequential  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

0 

o 

FTAM-2 

m 

m 

i 

1 

1 

1 

1 

1 

FTAM-4 

m 

m 

1 

1 

1 

1 

1 

1 

NBS-6 

m 

m 

1 

X 

X 

1 

X 

X 

NBS-12 

m 

m 

X 

X 

X 

X 

X 

X 

FTAM  ordered  flat 
constraint  set 

0 

o 

0 

0 

o 

o 

o 

0 

o 

NBS-6 

m 

1 

1 

1 

1 

i 

1 

m 

1 

FTAM  ordered  flat  constraint 
set  with  unique  names 

o 

o 

o 

o 

o 

o 

o 

NBS-11 

m 

1 

1 

1 

1 

m 

I 

NBS    ordered  flat 
constraint  set 

o 

o 

0 

o 

o 

o 

o 

0 

NBS-7 

m 

m 

m 

m 

1 

1 

1 

m 

NBS  random  access 
constraint  set 

o 

o 

o 

0 

NBS-10 

m 

m 

m 

m 
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Implementation  Profile  A1.3  (see  section  9.10) 


^^v^    FADU  Identity 
Constraint  Set 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Soq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM-1 

m 

FTAM-3 

m 

NBS-9 

m 

FTAM  sequential  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

FTAM-2 

m 

m 

m 

i 

i 

m 

1 

1 

FTAM-4 

m 

m 

m 

1 

i 

m 

1 

1 

NBS-6 

m 

m 

m 

X 

X 

m 

X 

X 

NBS-12 

m 

m 

m 

X 

X 

m 

X 

X 

FTAM  ordered  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

o 

NBS-8 

m 

m 

1 

1 

m 

m 

m 

m 

1 

FTAM  ordered  flat  constraint 
set  with  unique  names 

o 

o 

0 

o 

o 

o 

o 

NBS-11 

m 

m 

m 

m 

m 

m 

1 

NBS   ordered  flat 
constraint  set 

o 

o 

0 

c 

o 

0 

o 

o 

NBS-7 

m 

m 

m 

m 

m 

m 

m 

m 

NBS  random  access 
constraint  set 

o 

o 

o 

0 

NBS-10 

m 

m 

m 

m 
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A.I  3.1  FTAM-1   (See  section  10.7.1) 

A.I  3.1.1  Universal  class  number  parameter  (See  section  9.10.1) 


B  T1.3,  T2.3,  A1.3 


Universal  dass  number  parameter  supported 

0 

m 

PrintableString  - 

Universal  dass  19 

0 

1 

TeletexStrir>g 

Universal  dass  20 

0 

1 

VideotexString  - 

Universal  dass  21 

0 

1 

lASString 

Universal  dass  22 

0 

m 

see  9.10.1.1-2 

GraphicString 

Universal  dass  25 

0 

m 

see  A.13.1.3 

VisibleString 

Universal  dass  26 

0 

m 

GeneralString 

Universal  dass  27 

0 

m 

see  A.13.1.4 

A. 13.1.2  String  length  parameter  and  string  significance  parameter  combinations 

D 

T1.3,  T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

m 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

m 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

Unbounded  strings  and 
variable  length  strings 

o 

m 

Unbounded  strings  and 
not  significant  strings 

0 

m 

A.13.1.3  G  sets  supported 

G  sets  which  are  supported  in  FTAM-1  GraphicString.  

For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646,  IRV  (GO)  and  ISO  8859-1  (GO  and  Gl) 
character  sets  is  required, 
(see  9.10.1.1,  9.10.1.3) 
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A.13.1.4  G  and  C  Mts  supported 

G  and  C  sets  which  are  supported  in  FTAM-1  GeneralString 


December  1989 


1      For  value*  of  GeneralString  only  the  support  of  diaracter  strlnge  of  the  ISO  646,  IRV  (GO)  and  ISO  88S9-1  (GO  and  G1) 
character  sets  and  ISO  646  IRV  (CO)  control  character  set  Is  required 
(see  9.10.1-3) 


A.13.2  FTAM-2       (see  section  10.7.1) 


A.13.2.1  Universal  class  number  parameter  (see  section  9.10.1) 

D 

T2.3,  A1.3 

Universal  dass  number  parameter  supported 

0 

m 

PrintableString  - 

Universal  class  19 

0 

1 

TeletexString 

Universal  class  20 

0 

1 

VideotexString  - 

Universal  class  21 

0 

1 

lASString 

Universal  class  22 

0 

o 

see  9.10.1.1-2 

GraphicString 

Universal  class  25 

0 

m 

see  A. 13. 2. 3 

VisibleString 

Universal  class  26 

0 

m 

GeneralString 

Universal  class  27 

0 

o 

see  A. 13. 2. 4 

A.I 3.2.2  String  length  parameter  and  string  significance  parameter  combinations 


D 

T2.3,  A1.3 

1 

Maximum  string  ler^gth  parameter  and 
variable  length  strings 

0 

1 

2 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

1 

3 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

4 

Unbounded  strings  and 
variable  length  strings 

0 

1 

S 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.I  3.2.3  G  sets  supported 

G  sets  which  are  supported  in  FTAM-2  GraphicString. 
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For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646,  IRV  (GO)  and  (SO  8859-1  (GO  and  Gl) 
character  sets  Is  r&qulred. 
(see  9.10.1.1.  9.10.1.3) 


A.I  3.2.4  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  FrAM-2  GeneralString 


For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646,  IRV  (GO)  and  ISO  8859-1  (GO  and  Gl) 
character  sets  and  ISO  646  IRV  (CO)  control  character  set  Is  required, 
(see  9.10.1.1-3) 


A.13.3  FTAM-3 


A.13.3.1  String  length  parameter  and  string  significance  parameter  combinations  (see  section  10.7.1) 


D 

T1.3,  T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

1 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

1 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

UnbourKied  strings  and 
variable  length  strings 

o 

1 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.I 3.4.1  String  tength  parameter  and  string  significance  parameter  combinations 


D 

T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

1 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

1 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

Unbounded  strings  and 
variable  lenorh  strings 

o 

1 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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A.I  3.5.1  ParameterO 


See  tables  9.2,  9.3 


December  1989 


D 

T2.3,  A1.3 

ParameterO  supported 

m 

Universal-time 

Universal  class  23 

m 

Generalized-time 

Universal  class  24 

- 

m 

boolean 

Universal  dass  1 

m 

null 

Universal  dass  5 

m 

.,  .. 

A.13.5.2  Parameterl 

(see  section  9.10.1) 

n 

TO  AIT 

Parameterl  supported 

in 

integer 

Universal  dass  2 

m 

bit 

Universal  dass  3 

m 

IA5 

Universal  class  22 

m 

GraphicString 

Universal  class  25 

m 

GeneralString 

Universal  class  27 

m 

OctetString 

Universal  dass  4 

m 

A.1 3.5.3  Parameter2 

D 

T2.3,  A1.3 

Parameter2  supported 

o 
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A.13.6  NBS-7 

A.I  3.6.1  ParameterO 


Sm  tables  9.2,  9.3 
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D 

T2.3,  A1.3 

ParameterO  supported 

m 

Universal-time 

Universal  dass  23 

- 

m 

Generalized-time 

Universal  dass  24 

- 

m 

boolean 

Universal  dass  1 

- 

m 

null 

Universal  dass  5 

- 

m 

A.I  3.6.2  Parameterl 

(see  section  9.10.1) 

D 

T2.3,  A1.3 

Parameterl  supported 

m 

integer 

Universal  dass  2 

- 

m 

bit 

Universal  dass  3 

m 

IA5 

Universal  dass  22 

m 

GraphicString 

Universal  dass  25 

- 

m 

GeneralString 

Universal  dass  27 

- 

m 

OctetString 

Universal  dass  4 

m 

A.I  3.6.3  Parameter2 

D 

T2.3,  A1.3 

1 

Parameter2  supported 

o 
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December  1989 

S«e  tables  9.2,  9.3 

A  1    7  1  PflrAmetfirO 

n*lw*fal     r  Oi  oil     ioi  V 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D       T2  3  A1  3 

ParameterO  supported 

m 

m 

Universal-time 

Universal  dass  23 

m 

m 

Generalized-time 

Universal  dass  24 

m 

m 

boolean 

Universal  dass  1 

m 

null 

Universal  dass  5 

m 

(see  section  9.10.1) 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

U           1          A  1 .0 

Parameterl  supported 

m 

m 

integer 

Universal  dass  2 

m 

m 

D(t 

Universal  dass  3 

m 

Universal  dass  22 

m 

m 

Universal  dass  25 

m 

in 

GeneralString 

Universal  dass  27 

m 

m 

OctetString 

Universal  dass  4 

m 

m 

A.1 3.7.3  Parameter2 


Data  Types 

Key  Type 

D        T2.3,  A1.3 

D        T2.3,  A1.3 

Parameter2  supported 

o 

o 
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A.1 3.8.1  ParameterO 


See  tabids  9.2,  9.3 
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Data  Types 
D      T2.3,  A1.3 

Key  Type 

D        T2.3,  A1.3 

ParameterO  supported 

m 

m 

Universal-time 

Universal  class  23 

m 

m 

Generalized-time 

Universal  class  24 

m 

m 

boolean 

Universal  dass  1 

m 

null 

Universal  dass  5 

m 

A.I  3.8.2  Parameterl 

(see  section  9.10.1) 

Data  Types 

D       T2.3,  A1.3 

Key  Type 

D       T2.3,  A1.3 

Parameterl  supported 

m 

m 

integer 

Universal  dass  2 

m 

m 

bit 

Universal  dass  3 

m 

IA5 

Universal  class  22 

m 

m 

GraphicString 

Universal  class  25 

m 

m 

GeneralString 

Universal  class  27 

m 

m 

OctetString 

Universal  dass  4 

m 

m 

A.I  3.8.3  Parameter2 

Data  Types 

D       T2.3,  A1.3 

Key  Type 

D       T2.3,  A1.3 

Parameter2  supported 

o 

0 
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A.13.9  NBS-12    (see  sectlom 0.7.1) 

A.13.9.1  Universal  class  number  parameter  (see  section  9.10.1) 


D 

T2.3,  A1.3 

1 

Untversal  dass  number  parameter  supported 

m 

2 

PrintaWeString               -           Universal  class  19              -  1 

TeletexString                -           Universal  class  20              -  1 

VideotexString               -           Universal  class  21               -  1 

lASString                     -           Universal  class  22 

m 

GraphicString                -           Universal  dass  25 

m 

see  A.  13.9.5 

VisibleString                 -           Universal  class  26 

m 

GeneralString                -            Universal  class  27 

m 

see  A.  13.9.6 

A.1 3.9.2  String  length  parameter 

D 

T2.3,  A1.3 

Maximum  string  length  parameter  supported 

m 

A.1 3.9.3  String  significance  parameter 

D 

T2.3,  A1.3 

1 

Siring  significance  parameter  supported 

m 

2 

Variable  length  strings  supported 

m 

3 

Fixed  length  strings  supported 

m 

A.1 3.9.4  Character  set  parameter 

D 

T2.3,  A1.3 

1 

Character  set  parameter  supported 

m 
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A.1 3.9.5  G  sets  supported 

G  sets  which  are  supported  in  NBS-12  GraphicString.  

1      For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646,  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  is  required, 
(see  9.10.1.1,  9.10.1.3) 


A.1 3.9.6  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  NBS-12  GeneralString.  

1      For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646,  IRV  (GO)  and  ISO  8859-1  (GO  and  Gl) 
character  set  and  ISO  646  IRV  (CO)  control  character  sets  is  required, 
(see  9.10.1.1-3) 


-  END  OF  FTAM  PHASE  3  PROFILES  REQUIREMENTS  LIST  - 


) 
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I  APPENDIX  B  :    NIST  OIW  REGISTER  OF  FTAM  OBJECTS 


B.1  Introduction 

This  index,  the  NIST  OIW  Register  of  OIW  FTAM  objects,  contains  a  complete  list  of  all  FTAM  objects  as  defined 
by  NIST  OIW. 

NIST  OIW  was  authorized  by  BSI  in  its  letter  dated  August  09,  1989,  as  Registration  Authority  for  NIST  OIW  defined 
objects.  The  Object  Identifier  Prefix  for  OIW  is 

{ iso(1)  identified-organization{3)  oiw(14) } 

NIST  OIW  Plenary  has  delegated  the  authority  and  the  task  for  maintenance  of  the  NIST  OIW  Register  of  FTAM 
objects  to  its  FTAM  Special  Interest  Group  (SIG)  at  its  meeting  on  September  15,  1989.  The  Object  Identifier  Prefix 
for  the  FTAM  SIG  is 

{  iso(1)  identified-organization(3)  oiw(14)  ftamsig(5) } 

For  the  FTAM  Phase  2  dofinod  objects,  the  FTAM  SIG  has  decided  to  koop  tho  ad  hoc  Object  Identifier  values  as 
designated  in  1987  and  1988  with  the  not  necessarily  unique  Object  Identifier  Prefix 

 {  i60(1)  identified-'Organization(3)  icd(9999)  organization-codQ(1 ) } 

The  reason  is  that  FTAM  Phase  2  products  were  already  completed  and  released  to  users,  so  that  changing  these 
values  would  result  in  serious  intorworking  problems. 

For  each  new  OIW  FTAM  object  to  be  registered,  a  complete  technical  definition,  that  describes  the  purpose,  scope 
and  the  unique  characteristics  of  the  object,  must  be  prepared  and  presented  to  OIW  FTAM  SIG  for  technical 
discussion  and  acceptance,  and  for  final  approval  by  OIW  Plenary. 


10  -  64 


March  '90 

INDEX  of  QIW  FTAM  Objprts 
B.2.1    FTAM  Phase  2  Defined  Qbjorts 


I    Object  Identifier  Prefix  :    nist-adhoc  :=  iso(1)  identified-organization(3)  icd(9999)  organization-code(l) 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

NBS-6 

NBS-6  FTAM 
sequential  file 

{nist-adhoc 
document-type(5) 
sequentiai(6) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-1 77 
chapter  9,  appendix  A.I 

NBS-7 

NBS-7  FTAM  random 
access  file 

{nist-adhoc 
document-type(5) 
random-file(7) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-177 
chapter  9,  appendix  A.2 

NBS-8 

NBS-8  FTAM 
indexed  file 

{nist-adhoc 
document-type(5) 
indexed-filG(8) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-1 77 
chapter  9,  appendix  A. 3 

NBS-9 

NBS-9  FTAM  file 
directory  file 

{nist-adhoc 
document-type(5) 
file-directory(9) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-177 
chapter  9,  appendix  A.4 

NBS  ordered  flat 
constraint  set 

{nist-adhoc 
constraint-set(4) 
nbs-ordered-f[at(1) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-177 
chapter  9,  appendix  B.I 

kino    A  O  -4 

NBS-AS 1 

NBS  abstract 
syntax  AS1 

{nist-adhoc 
abstract-syntax(2) 
nbs-asl(l) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NIST  SP  500-177 
chapter  9,  appendix  C.I 

NBS-AS2 

NBS  file  directory 
entry  abstract  syntax 

{nist-adhoc 
abstract-syntax(2) 
nbs-as2(2) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-177 
chapter  9,  appendix  C.2 

AP-Title 

{nist-adhoc 
ftam-nil-ap-title(7) } 

Dec  15,  '89 

Stable  Agreements 
Vers.  3,  Ed.  1,  Dec  '89 
NISTSP  500-1 77 
section  5.12.1.1.1 
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Object  Identifier  Prefix  :    nist-oiw-ftam  :=  iso(1)  identified-organization(3)  oiw(14)  ftamsig(5) 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 

rit?y  loll  allUl  1 

Reference  to 

tJxSl  II IIIIUI 1 

NBS-6 

NBS-6  FTAM 
sequential  file 

{nist-oiw-ftam 
document-type(5) 
sequential(6) } 

March  1 6,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-1 77 

NBS-7 

NBS-7  FTAM  random 
access  file 

{nist-oiw-ftam 
document-type(5) 
random-file(7) } 

March  16,  '90 

Stable  Agreements 
Vers.  3.  Ed.  2,  March  '90 
NIST  SP  500-177 

NBS-8 

NBS-8  FTAM 
indexed  file 

{nist-oiw-ftam 
document-type(5) 
indexed-file(8) } 

March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-177 

NBS-9 

NBS-9  FTAM  file 
directory  file 

{nist-oiw-ftam 
document-type(5) 
file-directory(9) } 

March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-177 

L/iicl|JLc;l        ctlJiJcilUIA  r\.0 

NBS  ordered  flat 
constraint  set 

{nist-oiw-ftam 
constraint-set(4) 
nbs-ordered-flat(1 ) } 

March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NISTSP  500-177 
chapter  9,  appendix  B.2 

NBS-AS1 

NBS  abstract 
syntax  AS1 

{nist-oiw-ftam 
abstract-syntax  (2) 
nbs-as1(1) } 

March  1 6,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2,  March  '90 
NIST  SP  500-177 
chapter  9,  appendix  C.3 

NBS-AS2 

NBS  file  directory 
entry  abstract  syntax 

{nist-oiw-ftam 
abstract-syntax  (2) 
nbs-as2(2) } 

March  16,  '90 

Stable  Agreements 
Vers.  3,  Ed.  2.  March  '90 
NIST  SP  500-177 
chapter  9,  appendix  C.4 
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B.2.2    FTAM  Phase  3  Defined  Objects 


j    Object  identifier  Prefix  :    nist-oiw-ftam  :=  iso(1)  identified-organ!2ation(3)  oiw(14)  ftamsig(5) 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

NBS-10 

NBS-10  random 
binary  access  file 

{nist-oiw-ftam 
document-type(5) 
random-binary(IO) } 

Dec  15,  "89 

Stable  Agreements 
Vers.  3,  Ed.  1,  Dec  '89 
NISTSP  500-177 
chapter  10,  appendix  C.I 

NBS-11 

NBS-11  FTAM  Indexed 
file  with  unique  keys 

{nist-oiw-ftam 
document-type(5) 
indexed-file-with-unique- 
l<eys(11) } 

Dec  15,  '89 

Stable  Agreements 
Vers.  3,  Ed.  1 .  Dec  '89 
NIST  SP  500-177 
chapter  1 0,  appendix  C.2 

NBS-12 

NBS-12  FTAM 
simple  text  file 

{nist-oiw-ftam 
document-type(5) 
simple-text-file(12) } 

Dec  15,  '89 

Stable  Agreements 
Vers.  3,  Ed.  1 ,  Dec  '89 
NISTSP  500-177 

NBS  Random  Access 

{nist-oiw-ftam 
constraint-set(4) 
nbs-random-access(2) } 

Dec  1 5,  '89 

Stable  Agreements 
Vers.  3,  Ed.  1 ,  Dec  '89 
NISTSP  500-177 

Ltldpic^l    1  U,  appollUiA  1 

NBS-AS3 

NBS  random  access 
node  name  abstract 
syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-node-name(3) } 

Dec  15,  '89 

Stable  Agreements 
Vers.  3,  Ed.  1,  Dec  '89 
NISTSP  500-1 77 
chapter  10,  appendix  E.I 

NBS-AS4 

NBS  random  binary 
access  file 
abstract  syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-random-binary(4) } 

Dec  15,  '89 

Stable  Agreements 
Vers.  3,  Ed.  1 ,  Dec  '89 
NIST  SP  500-177 
chapter  10,  appendix  E.2 

NBS-AS5 

NBS  simple  text 
abstract  syntax 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-simple-text(5) } 

Dec  15,  '89 

Stable  Agreements 
Vers.  3,  Ed.  1.  Dec  '89 
NIST  SP  500-177 
chapter  10,  appendix  E.3 
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1:0.-1:2    APPENDIX  C:  DOCUMENT  TYPES 
C . 1         NBS-10  Random  Binary  Access  Document  Type 

1.  Entry  Number:  NBS-10 

2.  Information  objects 


Table  10.2.     Information  objects  in  NBS-10 


document  type  name 

! 

{iso  identif ied-organization 
oiw(14)  ftamsig(5)  document- 

type(5)  rando'^-birjary ( 10)  ) 
"NBS-10  random  binary  access  file" 

abstract  syntax  names: 

a)  name  of  asnamel 

b)  name  of  asname2 

c)  name  of  asname3 

{iso  identif ied-organization 

oiw(14)  rtamsig(D;  abstract- syntax(Z) 

nbs- random-binary (4) ) 

"NBS  random  binary  access  file  abstract 
syntax" 

{iso  standard  8571  abstract- syntax( 2)  ftam- 
fadu(2)} 

"FTAM  FADU" 
{iso  identif ied-organization 
oiw(14)  ftamsig(5)  abstract- syntax(2) 
nbs-node-name(3) } 

"NBS  random  access  node  name  abstract 
syntax" 

transfer  syntax  names: 

{ joint-iso-ccitt  asnl(l)  basic-encoding(l) } 
"Basic  encoding  of  a  single  ASN.l  type" 

file  model 

{iso  standard  8571  f ile-model(3) 
hierarchical(l) ) 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  identif ied-organization 
oiw(14)  ftamsig(5)  constraint-set (4) 
nbs-random-access (2) )  "NBS  random  access 
constraint  set" 

File  contents: 

Datatypel  : :=  a  single  octet 

Datatype2  : :=  Node -Name 
--The  type  to  be  used  for  Node-Name  is  defined  in 
--ISO  8571-FADU 

--The  only  Choice  for  Node-Name  is  user-coded 
Datatypes  : :=  NBS -Node-Name 
--As  defined  by  the  NBS  Node  Name  Abstract  Syntax 
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3.  Scope  and  field  of  application 

This  document  type  defines  the  contents  of  a  file  for  storage,  for 
transfer  and  access  by  FTAM. 

4 .  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems 
Interconnection  -File  Transfer,  Access  and  Management 

5 .  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and 
file  access  data  unit  as  defined  in  ISO  8571-1. 

6 .  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

7.  Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units 
each  of  which  consists  of  one  data  element.     The  data  element  is  made 
up  of  one  octet.     The  order  of  these  elements  is  significant.  The 
semantics  of  the  data  elements  is  not  specified  by  this  document  type. 

The  document  structure  takes  the  form  allowed  by  the  FTAM 
hierarchical  file  model  as  constrained  by  the  NBS  random  access 
constraint  set.     The  definition  for  FTAM  hierarchical  file  model 
appears  in  8571-2. 

There  are  no  size  or  length  limitations  imposed  by  this  definition. 

8.  Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  series  of 
octets . 

9.  Definition  of  transfer 

9.1.         Datatype  definition 

The  presentation  data  value  used  for  transfer  is  an  ASN.l  OCTET 
STRING . 

Datatype2  is  used  to  specify  the  FADU- Identity  of  "name-list"  in 
th3  FTAM  PDUs  specifying  FADU -Identity,  where  "name-list"  is 
defined  as  a  SEQUENCE  of  EXTERNAL.     The  EXTERNAL  is  defined  as 
Node-Name  in  the  FTAM  FADU  abstract  syntax.     The  use  of  Datatype2 
is  defined  in  "NBS  random  access  constraint  set." 
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Datatypes  specifies  the  "user-coded"  form  of  the  Node-Name  in  the 
FTAM  FADU  abstract  syntax,  where  "user-coded"  is  defined  as  an 

EXTERNAL.     That  EXTERNAL  is  defined  by  Datatypes.     The  use  of 
Datatypes  is  defined  in  "NBS  random  access  constraint  set." 

9 . 2  Presentation  data  values 

The  document  is  transmitted  as  a  series  of  presentation  data 
values.     Each  presentation  data  value  shall  consist  of  the  "data" 
from  one  or  more  FADUs  concatenated  together.     The  result  is  one 
value  of  the  ASN.l  data  type  OCTET  STRING.     The  "fadu_count" 
field  supplied  in  the  Node-Name  specifies  the  number  of  FADUs  to 
transfer  during  a  Read  operation.     The  requested  FADUs  may  be 
transferred  as  one  or  more  presentation  data  values. 

All  values  are  transmitted  in  the  same  (but  any)  presentation 
context  established  to  support  the  abstract  syntax  name  "asnamel" 
declared  in  table  10.2. 

Note:  Specific  carrier  standards  may  impose  additional 

constraints  on  the  presentation  context  to  be 
used,  when  the  above  permits  a  choice. 

Boundaries  between  P-DATA  primitives  and  between  presentation 
data  values  are  chosen  locally  by  the  sending  entity  at  the  time 
of  transmission.     The  boundaries  are  not  preserved  when  the  file 
is  stored  and  they  carry  no  semantics  of  the  document  type. 
Receivers  which  support  this  document  type  shall  accept  a 
document  with  any  of  the  permitted  transfer  options. 

9 . 3  Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  is  the  same  as  the 
sequence  of  Data  Units  within  the  file. 

10.  Transfer  syntax 

An  implementation  supporting  these  document  types  shall  support 
the  transfer  syntax  generation  rules  named  in  table  10.2  for  all 
presentation  data  values  transferred. 

Implementations  may  optionally  support  other  transfer  syntaxes. 

11.  ASE  specific  specifications 

11.1        Simplification  and  relaxation 

The  document  type  NBS- 10  may  be  simplified  to  the  document  type 
FTAM-3.     The  resultant  document  contains  the  same  sequence  of 
data  values  as  would  result  from  accessing  the  file  as  an  NBS- 10 
file. 
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11.2  The  READ  operation 

A  READ  operation  may  be  applied  to  a  range  of  FADUs  via  the  FADU 
Identity  of  "NodeSeq."    The  "starting-fadu"  part  of  the  node 
name  specifies  the  node  number  of  the  first  FADU;  the  "fadu- 
count"  specifies  the  number  of  consecutive  FADUs  to  be 
transferred. 

A  READ  operation  applied  to  a  range  of  FADUs  that  spans  beyond 
the  end  of  file  is  valid.     All  available  data  in  the  range  is 
transferred.    An  informative  diagnostic  (5005)  is  returned  on  the 
F-Data-End  Request  indicating  that  the  end  of  file  was  reached 
and  a  portion  of  the  request  was  satisfied. 

11.3  The  REPLACE  operation 

When  the  REPLACE  operation  is  applied  to  the  root  FADU  of  an  NBS- 
10  document,  the  transferred  data  shall  be  any  NBS-10  document. 

The  REPLACE  operation  applied  to  a  FADU  identity  of  "node 
number"  is  used  to  replace  a  series  of  FADUs,  starting  at  the 
specified  position  in  the  file,  by  the  new  FADUs  being 
transferred.     The  number  of  replaced  FADUs  is  determined  by  the 
number  of  transferred  FADUs. 

If  the  replacement  spans  beyond  the  end  of  the  existing  file, 
then  the  additional  FADUs  are  inserted  at  the  end  of  the  file. 

11.4  The  INSERT  operation 

When  the  INSERT  operation  is  applied  at  the  end  of  file,  the 
transferred  data  shall  be  a  series  of  FADUs  which  would  be 
generated  by  reading  any  NBS-10  document  type  in  access  context 
UA. 
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C. 2  NBS-11        Indexed  Sequential  File  With  Unique  Keys 

1.  Entry  Number:  NBS-11 

2.  Information  objects 

Table  10.3.     Information  objects  in  NBS-11 


document  type  name 

{iso  identif ied-organization 
oiw(14)  ftamsig(5)  document- type (5) 
indexed-f ile-with-unique-keys (11) ) 
"NBS-11  FTAM  indexed  file  with  unique  keys" 

abstract  S3mtax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identif ied-organization  oiw(14) 
ftarasig(5)  organization-eode(-t) 
abstract  S3mtax(2)  nbs-asl(l)) 

"NBS  abstract  syntax  ASl" 
{iso  standard  8571  abstract-syntax(2)  ftam- 
fadu(2) } 

"FTAM  FADU" 

transfer  syntax  names: 

{ joint-iso-ccitt  asnl(l)  basic-encoding(l) 
) 

"Basic  Encoding  of  a  single  ASN.l  type" 

parameter  syntax: 

PARAMETERS  : :=  SEQUENCE                    {DataTypes,  KeyType,  KeyPosition) 

DataTypes     : :=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl ,  Parameter2) 

KeyType        : :=  CHOICE  {ParameterO,  Parameterl,  Parameter2) 

ParameterO,  Parameterl,  Parameter2,  as  defined  for  the 
--     document  types  NBS-6,  NBS-7,  NBS-8 

KeyPosition: :=  INTEGER 

file  model 

{iso  standard  8571  f ile-model(3) 
hierarchical(l) ) 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set (4) 
ordered- flat-unique-names (4) } 
"FTAM  ordered  flat  constraint  set  with 
unique  names" 

file  contents: 

Datatypel  :  :=  PrimTjrpe  --  as  defined  in  Appendix  9C,  C.3 

Annex  -9  -A ,-  -Part  -3 
of  NIST  SP  500-t62  177 
Datatype2  : :=  CHOICE      {  Node-Descriptor-Data-Element, 

Enter-Subtree-Data-Element  ) 
Exic-Suocree-Data-Element  } 
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3.  Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for 
transfer  and  access  using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  Virtual 

Filestore. 

4.  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems 
Interconnection  -File  Transfer,  Access  and  Management 

5.  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and 
file  access  data  unit  as  defined  in  ISO  8571-1. 

6 .  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

7.  Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units, 
each  of  which  consists  of  zero,  one  or  more  data  elements.     The  order 
of  each  of  these  elements  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM 
hierarchical  file  model  as  constrained  by  the  FTAM  ordered  flat 
constraint  set  with  unique  names  (see  table  10.3).     These  definitions 
appear  in  ISO  8571-2. 

The  following  additional  requirements  are  specified  for  the  use  of 
the  ordered  flat  constraint  set  with  unique  names: 

o        The  FADU  identity  'node  number'  is  not  required  for 
conformant  implementations 

o       The  identities  'next'  and  'previous'  are  allowed  for  all 
FADUs 

Each  data  element  is  a  data  type  from  the  set  of  primitive  data  types 
defined  in  Appendix -9A,- -Part -S -of -NIST -5GG-t&2  Appendix  9C,  C.3  of 
NIST  SP  500-177.     Each  data  unit  contains  the  same  data  element  types 
in  the  same  order  as  all  other  data  units.     These  types  and  their 
respective  maximum  lengths  are  defined  by  the  <DataTypes>  parameter. 
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NBS-11  Indexed  Sequential  File  With  Unique  Keys 

1.  Entry  Number:  NBS-11 

2.  Information  objects 

Table  10.3.     Information  objects  in  NBS-11 


document  type  name 

{iso  identif ied-organization 
oiw(14)  ftamsig(5)  document- type (5) 
indexed- file -wi th-unique - key s (11)} 
"NBS-11  FTAM  indexed  file  with  unique  keys" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identif ied-organization  icd(9999) 
organization-code(l)  abstract- 
syntax(2)  nbs-asl(l)) 

"NBS  abstract  syntax  ASl" 
{iso  standard  8571  abstract-syntax(2)  ftam- 
fadu(2) ) 

"FTAM  FADU" 

transfer  syntax  names: 

( joint-iso-ccitt  asnl(l)  basic-encoding( 1 ) 
} 

"Basic  Encoding  of  a  single  ASN.l  type" 

parameter  syntax: 

PARAMETERS  : :=  SEQUENCE                    {DataTypes,  KeyType,  KeyPosition} 

DataTypes     : :=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameter 1 ,  Parameter2} 

KeyType        : :=  CHOICE  {ParameterO,  Parameterl ,  Parameter2} 

ParameterO,  Parameterl,  Parameter2,  as  defined  for  the 
--    document  types  NBS-6,  NBS-7,  NBS-8 

KeyPosition: :=  INTEGER 

file  model 

{iso  standard  8571  f ile-model(3) 
hierarchical ( 1 ) ) 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4) 
ordered-f lat-unique-naraes(4) } 
"FTAM  ordered  flat  constraint  set  with 
unique  names" 

file  contents: 

Datatypel  : :=  PrimType  --  as  defined  in  Annex  9  A,  Part  3 

of  NIST  SP  500-162 

Datatype2  ::=  CHOICE      {  Node-Descriptor-Data-Element, 

Enter-Subtree-Data-Element  } 
Exit-Subtree-Data-Element  ) 
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3.  Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for 
transfer  and  access  using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  Virtual 

Filestore. 

4 .  References 

ISO  8571,   Information  Processing  Systems  -  Open  Systems 
Interconnection  -File  Transfer,  Access  and  Management 

5 .  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and 
file  access  data  unit  as  defined  in  ISO  8571-1. 

6 .  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

7.  Document  semantics 

The  docximent  consists  of  zero,  one  or  more  file  access  data  units, 
each  of  which  consists  of  zero,  one  or  more  data  elements.     The  order 
of  each  of  these  elements  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM 
hierarchical  file  model  as  constrained  by  the  FTAM  ordered  flat 
constraint  set  with  unique  names  (see  table  10.3).     These  definitions 
appear  in  ISO  8571-2. 

The  following  additional  requirements  are  specified  for  the  use  of 
the  ordered  flat  constraint  set  with  unique  names: 

o       The  FADU  identity  'node  number'  is  not  required  for 
conformant  implementations 

o       The  identities  'next'  and  'previous'  are  allowed  for  all 
FADUs 


Each  data  element  is  a  data  type  from  the  set  of  primitive  data  types 
defined  in  Appendix  9A,  Part  3  of  NIST  500-162.     Each  data  unit 
contains  the  same  data  element  types  in  the  same  order  as  all  other 
data  units.     These  types  and  their  respective  maximum  lengths  are 
defined  by  the  <DataTypes>  parameter. 
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The  string- length  field  of  Parameter  1  specifies  the  length  of  the 
value  in  octets  for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types. 
For  character- type  data  elements,  the  string-length  indicates  the 
actual  number  of  characters  from  the  specified  character  set,  not 
including  any  escape  sequences  or  overhead  from  the  character 
encoding . 

For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify 
the  length  in  bits  of  mantissa  and  exponent,  respectively.  The 
length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of 
floating  point  numbers. 

Each  data  unit  in  the  file  has  a  key  associated  with  it,  which  is  the 
user-coded  form  of  Node  Name.     The  key  of  each  data  unit  is  of  the 
same  data  type  as  the  key  of  all  other  data  units  in  the  file  and  is  a 
single  data  element  from  the  set  of  primitive  data  types  defined  in 

I        Appendix -9A,- -Part -S -of -NIST-5GG-1:62t    Appendix  9  C,  C.3  of  NIST  SP 

I  500-177. 

The  type  and  length  of  the  key  are  defined  by  the  <KeyType> 
parameter . 

The  primitive  data  types  and  minimum  size  ranges  of  each  unit  which 
an  implementation  must  accept  as  a  key  value  are  given  in  the 
following  table  10.4. 


Table  10.4.     Datatypes  for  keys 


Kev  Tvpe 

Minimum  Range  (octets) 

Order 

ASN.l  INTEGER 

(1-2) 

increasing  numeric  value 

ASN.l  lASString 

(1-16) 

lexical  order 

ASN.l  GraphicString 

(1-16) 

lexical  order 

ASN.l  GeneralString 

(1-16) 

lexical  order 

ASN.l  OCTET  STRING 

(1-16) 

increasing  value 

ASN.l  GeneralizedTime 

increasing  time  value 

ASN.l  UniversalTime 

increasing  time  value 

NBS-ASl  FloatingPointNumber 

increasing  numeric  value 

The  position  of  the  key  in  the  data  unit  is  specified  by  the 
<KeyPosition>  parameter. 

KeyPosition  =  0  implies  the  key  is  not  part  of  the  data 
KeyPosition  >  0  specifies  the  actual  data  element  in  the  data  unit. 

8.  Abstract  syntactic  structure 
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The  abstract  syntactic  structure  of  the  document  is  a  hierarchically 
structured  file  as  defined  in  the  ASN.l  module  IS08571-FADU  in  ISO 
8571,  in  which  each  of  the  file  access  data  units  has  the  abstract 
syntactic  structure  of  NBS-ASl  as  defined  by  the  parameters. 

Definition  of  transfer 

1  Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  10.3,  where  the  PrimType  in  the 
datatjrpe  is  given  by  the  NBS-ASl  definition;  or 

b)  Datatype2  defined  in  table  10.3,  which  is  the  ASN.l  datatype 
declared  as  "Data-Element"  in  the  ASN.l  module  IS08571-FADU. 

2  Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data 
values,  each  of  which  is  either 

a)  one  value  of  the  ASN.l  datatype  "Datatypel,"  carrying  one 
of  the  data  elements  from  the  document.     All  values  are 
transmitted  in  the  same  (but  any)  presentation  context 
defined  to  support  the  abstract  syntax  name  "asnamel"  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the 
same  (but  any)  presentation  context  defined  to  support  the 
abstract  syntax  name  "asname2." 

Notes:  1.  Specific  carrier  standards  may  impose  additional 
constraints  on  the  presentation  context  to  be 
used,  where  the  above  permits  a  choice 

2.  Any  document  type  defined  in  this  entry  either 
makes  no  use  of  Datatype2 ,  or  starts  with  a 
Datatype2  transmission. 

Boundaries  between  presentation  data  values  in  the  same 
presentation  context,  and  boundaries  between  P-DATA  primitives, 
are  chosen  locally  by  the  sending  entity  at  the  time  of 
transmission,  and  carry  no  semantics  of  the  document  type. 
Receivers  which  support  this  document  type  shall  accept  a 
document  with  any  of  the  permitted  transfer  options  (e.g., 
document  type  parameters  and  transfer  syntaxes) . 

3  Sequence  of  presentation  data  values 
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The  sequence  of  presentation  data  values  of  type  a)  and  the 
sequence  of  presentation  data  values  of  types  a)  and  b)  is  the 
same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and 
Data  Units  in  the  hierarchical  structure,  when  flattened 
according  to  the  definition  of  the  hierarchical  file  model  in 
ISO  8571-2. 

10.  Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support 
the  transfer  syntax  generation  rules  named  in  table  10.2  for  all 
presentation  data  values  transferred.     Implementation  may 
optionally  support  other  named  transfer  sjmtaxes. 

11.  ASE  specific  specifications  for  FTAM 
11.1        Simplification  and  relaxation 


11.1.1    Structural  simplification 

This  simplification  loses  information. 

The  document  type  NBS-11  may  be  accessed  as  a  document  type 
FTAM- 3     (allowed  only  when  reading  the  file)  by  specifying 
document  type  FTAM- 3  in  the  <contents  type>  parameter  in  <F- 
OPEN  request>,  and  limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is 
unpredictable.     It  will  usually  correspond  to  the  data  values  as 
stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-11  can  be  accessed  as  a  document  of  type 
NBS-6  (allowed  only  when  reading  the  file)  by  specifying 
document  type  NBS-6  with  appropriate  data  type  parameters  in  the 
<contents  type>  parameter  on  the  <F-OPEN  request>.  The 
traversal  order  of  the  FADUs  must  be  maintained. 

Note:  The  traversal  order  is  as  reading  the  file  as  NBS-11  in 

key  order. 

A  document  of  type  NBS-11  may  be  accessed  as  a  document  of  type 
NBS-8  (allowed  only  when  reading  the  file)  by  specifying 
document  type  NBS-8  in  the  <contents  type>  parameter  in  the  <F- 
OPEN  REQUEST>. 

11.2       Access  context  selection 

A  document  of  type  NBS-11  may  be  accessed  in  any  one  of  the 
access  contexts  defined  in  the  FTAM  ordered  flat  constraint  set 
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with  unique  names.     The  presentation  data  units  transferred  in 
each  case  are  those  derived  from  the  structuring  elements  defined 
for  that  access  context  in  ISO  8571-2, 

11.3  The  INSERT  operation 

When  the  <INSERT>  operation  is  applied  the  transferred  material 
shall  be  the  series  of  FADU  which  would  be  generated  by  reading 
any  NBS-11  document  with  the  same  parameter  values  in  access 
context  FA. 

A  transferred  FADU  whose  name  duplicates  that  of  an  already 
existing  FADU  will  cause  the  <INSERT>  operation  to  fail.  The 
failure  shall  be  signalled  by  issuing  an  F-CANCEL  Request  with  a 
corresponding  diagnostic. 

11.4  The  EXTEND  operation 

This  operation  is  excluded  for  the  use  with  this  document  type. 

11.5  The  REPLACE  operation 

When  the  <REPLACE>  operation  is  applied  with  FADU  Identity 
'begin' ,  a  transferred  FADU  whose  name  duplicates  that  of  a 
previously  transferred  FADU  will  cause  the  <REFLACE>  operation 
to  fail.     The  failure  shall  be  signalled  by  issuing  an  F-CANCEL 
Request  with  a  corresponding  diagnostic. 
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I  C. 3  NBS-12        Simple  Text  File  Document  Type 

1.  Entry  Number:  NBS-12 

2.  Information  objects 


Table  10.5.     Information  objects  in  NBS-12 


document  type  name 

{iso  identif ied-organization 
oiw(14)  ftamsig(5)  document- 
type(5)  simple-text-file(12) } 
"NBS-12  FTAM  simple  text  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identif ied-organization 
oiw(14)  ftamsig(5)  abstract-syntax(2) 
nbs-simple-text(5) ) 
"NBS  simple  text  abstract  syntax" 
{iso  standard  8571  abstract-syntax(2)  ftam- 
fadu(2) ) 

"FTAM  FADU" 

transfer  sjmtax  names: 

{ joint-iso-ccitt  asnl  (1)  basic-encoding  (1)) 
"Basic  Encoding  of  a  single  ASN.l  type" 

Parameter  Syntax 
PARAMETERS  : :=  SEQUENCE { 

universal -class -number  [0]  IMPLICIT  INTEGER, 
maximum- string- length     [1]   IMPLICIT  INTEGER, 

string-significance         [2]   IMPLICIT  INTEGER  {variable  (0),   fixed  (1)}, 
character-set                   [3]   IMPLICIT  OctetString  OPTIONAL) 

file  model 

{iso  standard  8571  f ile-model(3) 
hierarchical(l) ) 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set (4) 
sequential  flat(2)} 

"FTAM  sequential  flat  constraint  set" 

File  contents 

Datatype 1  : :=  NBS  Text 

--as  defined  in  the  NBS  Simple  Text 
--Abstract  Syntax  registration  entry 

Datatype2  : :=  Node-Descriptor-Data-Element 

3.  Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  and  for 
transfer  and  access  by  FTAM. 
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4.  References  ^ 

ISO  8571,   Information  Processing  Systems  -  Open  Systems  Interconnection  - 
File  Transfer,  Access  and  Management 

ISO  8824,  Information  Processing  Systems-Open  Systems  Interconnection- 
Specification  of  Abstract  Syntax  Notation  1  (ASN.l). 

ISO  8825,   Information  Processing  Systems-Open  Systems  Interconnection- 
Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.l). 

ISO  6429,   Information  Processing-ISO  7-bit  and  8-bit  coded  character  sets- 
Additional  control  functions  for  character  imaging  devices. 

5.  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file 
access  data  unit  as  defined  in  ISO  8571-1.     In  addition,   it  makes  use  of  the 
terms  character  string,  graphics  character,  and  format  effector  as  defined 
in  document  type  registration  entry  "FTAM-2"  ir  ISO  8571-2. 

6 .  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

7 .  Document  semantics  ^ 

This  document  consists  of  zero,  one  or  more  file  access  data  units,  each  of 
which  consists  of  one  character  string.     The  order  of  each  of  these  elements 
is  significant.     The  semantics  of  the  character  strings  is  not  specified  by 
this  document  type. 

The  docviment  structure  takes  any  of  the  forms  allowed  by  the  FTAM 
hierarchical  file  model  as  constrained  by  the  sequential  flat  constraint 
set.     These  definitions  appear  in  ISO  8571-2.     As  additional  constraints 
FADU  identity  will  be  limited  to  the  following  values: 

a)  'begin'  and  'end'  when  using  the  Transfer  or  Transfer  and 
Management  service  classes. 

b)  'begin',    'end',    'first',  and  'next'  when  using  the  Access  service 
class . 

Each  character  string  consists  of  characters  from  the  character  set  defined 
by  the  ASN.l   (ISO  8824)  character  set  type  whose  universal  class  number  is 
given  by  the  "universal-class-number"  parameter  and  by  the  escape  sequences 
contained  in  the  optional  "character-set"  parameter.     If  the  character  set 
type  allows  explicit  escape  sequences,   the  "character-set"  parameter,  if 
present,  contains  escape  sequences  which  designate  and  invoke  specific 


( 
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character  sets.     If  the  "character-set"  parameter  is  not  present,  character 
sets  are  assumed  to  be  designated  and  invoked  as  specified  in  table  2  in  ISO 
8825.     Character  strings  shall  not  contain  escape  sequences. 

There  are  no  size  or  length  limitations  imposed  by  this  definition,  except 
those  specified  here.     Each  character  string  is  of  a  length  determined  by 
the  number  of  characters  given  by  the  "maximum- string- length"  parameter. 

Note:  The    length    restriction   refers    to    the    number    of  characters 

from  the  applicable  character  set,  not  to  the  number  of 
octets  in  the  encoding,  nor  to  the  line  length  in  any 
rendition  of  the  document,  where  these  are  different. 

The  exact  significance  of  the  character  strings  is  determined  by  the 
" string- s ignificance "  parameter.     If  its  value  is  "variable,"  the  length  of 
the  character  strings  is  less  than  or  equal  to  the  length  given.     If  the 
value  is  "fixed,"  the  length  of  each  character  string  is  exactly  equal  to 
the  length  given. 

If  the  document  is  interpreted  on  a  character  imaging  device  (outside  the 
scope  of  ISO  8571),   the  interpretation  depends  on  the  character  set  in  use. 

a)  If  the  character  set  contains  format  effectors,   they  shall  be 
interpreted  as  defined  in  ISO  6429;   end  of  string  and  end  of  file 
access  data  unit  are  given  no  formatting  significance,   and  do  not 
contribute  to  the  document  semantics; 

b)  If  the  character  set  does  not  contain  format  effectors,   the  end  of 
each  character  string  is  interpreted  as  implying  carriage  return 
and  line  feed  formatting  actions  in  any  rendition.     The  end  of 
file  access  data  unit  is  given  no  formatting  significance  beyond 
that  attached  to  the  end  of  the  string  in  it. 

8.  Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically 
structured  file  as  defined  in  the  ASN.l  modules  IS08571-FADU  and  ISO  8571- 
CONTENTS  in  ISO  8571,   in  which  each  of  the  file  contents  data  elements  has 
the  abstract  syntactic  structure  of  "NBS  Simple  Text." 

9.  Definition  of  transfer 
9.1  Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)       Datatypel  defined  in  table  10.5,   the  ASN.l  datatype  declared  as 

"NBS -Text"  in  the  NBS  Simple  Text  Abstract  Syntax  definition.  The 
choice  in  "NBS-Text"  is  determined  by  the  universal-class-number 
parameter;  or 
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b)      Datatype2  defined  in  table  10.5,  the  ASN.l  datatype  declared  as 
"Data-Element"  in  the  ASN.l  module  ISO  8571-FADU. 

9.2  Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values , 
each  of  which  is  either 

a)  one  value  of  the  ASN.l  datatype  "Datatypel , "  carrying  one  of  the 
character  strings  of  the  document.     Each  character  shall  be 
transmitted  using  one  of  the  character  sets  identified  by  the 
universal -class -number  parameter.     All  values  are  transmitted  in 

' the  same  (but  any)  presentation  context  established  to  support  the 
abstract  syntax  name  "asnamel"  declared  in  table  10.5,  or 

b)  one  value  of  the  ASN.l  datatype  "Datatype2."     All  values  are 
transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2" 
declared  in  table  10.5. 

Notes:        1.       Specific  carrier  standards  may  impose  additional 

constraints  on  the  presentation  context  to  be  used, 
where  the  above  permits  a  choice. 

2.      Any  document  type  defined  in  this  entry  either 
makes  no  use  of  Datatype2,  or  starts  with  a 
Datatype2  transmission. 

,         Boundaries  between  P-DATA  primitives  are  chosen  locally  by  the  sending 
entity  at  the  time  of  transmission,  and  carry  no  semantics  of  the 
document  type.     Receivers  which  support  this  document  type  shall  accept 
a  document  with  any  of  the  permitted  transfer  options. 

9 . 3  Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  (a)  and  the  sequence 
of  presentation  data  values  of  types  (a)  and  (b)  is  the  same  as  the 
sequence  of  character  strings  within  a  Data  Unit,  and  Data  Units  in  the 
hierarchical  structure,  when  flattened  according  to  the  definition  of 
the  hierarchical  file  model  in  ISO  8571-2. 

10.  Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the 
transfer  syntax  generation  rules  named  in  table  10.5  for  all 
presentation  data  values  transferred. 

11.  ASE  specific  specifications 
11.1        Simplification  and  relaxation 


11.1.1    Simplification  to  FTAM-1 
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This  simplification  loses  information. 

The  document  type  NBS-12  may  be  accessed  as  a  document  type  FTAM- 

1 .  The  resultant  document  contains  the  same  sequence  of  data 
values  as  would  result  from  accessing  the  structured  text  file  in 
access  context  UA.     That  is,  only  the  presentation  data  values  in 
the  abstract  syntax  "asnamel"  are  present.     If  the  "character-set" 
parameter  was  present  before  the  simplification,   its  contents  will 
be  added  to  the  beginning  of  each  string. 

Note:  The  boundary  between  file  access  data  units  remains 

a  boundary  between  strings,  but  any  special 
significance  given  to  it  is  lost. 

11.1.2  Relaxation  to  FTAM-2 

The  document  type  NBS-12  may  be  relaxed  to  the  document  type  FTAM- 

2.  If  the  "character-set"  parameter  was  present  before  the 
relaxation,   its  contents  will  be  added  to  the  beginning  of  each 
string . 

11.1.3  Character  set  relaxation 

This  operation  loses  explicit  information  in  the  document  type 
identification. 

A  document  of  type  NBS-12  may  be  relaxed  to  a  different  document 

of  type  NBS-12  with 

o        a  different  "universal-class-number"  parameter  value, 

o        a  different  "character-set"  parameter  value, 
o        different  values  for  both  of  these  parameters, 

o        a  different  "universal-class-number"  parameter  value  and  no 
"character-set"  parameter  value,  or 

o        no  "character-set"  parameter  value, 

if  the  resultant  document  type  permits  all  characters  from  the 
original  document  type.     If  this  relaxation  involves  including 
format  effectors  and  none  were  present  before  the  simplification, 
the  characters  "carriage  return"  and  "line-feed"  shall  be  added  to 
the  end  of  each  string. 

Note:  If  the  characters  "carriage  return"  and  "line  feed" 

are  not  part  of  the  format  effectors,  the 
formatting  action  may  be  represented  by  "newline," 
or  some  other  implementation  specific  choice  if 
there  is  no  representation  of  "newline"  defined. 


11.1.4    String  length  relaxation 
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This  operation  loses  explicit  information  in  the  document  type 
identification. 

A  document  of  type  NBS-12  may  be  relaxed  to  another  document  type 
NBS-12  with  a  larger  "maximum- string- length"  parameter. 

11.2  Access  context  selection 

A  document  of  type  NBS-12  may  be  accessed  in  any  one  of  the  access 
contexts  defined  in  the  sequential  flat  constraint  set.  The 
presentation  data  units  transferred  in  each  case  are  those  derived  from 
the  structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 

11.3  The  INSERT  operation 

When  the  INSERT  operation  is  applied  at  the  end  of  file,  the 
transferred  material  shall  be  the  series  of  FADUs  which  would  be 
generated  by  reading  any  NBS-12  document  type  with  the  same  parameter 
values  in  access  context  FA. 
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10.-1:3  APPENDIX  D:         CONSTRAINT  SETS 

D.l    NBS  Random  Access  Constraint  Set 

Table  10.6.     Basic  constraints  in  the  NBS  Random  Access  Constraint  Set 


Constraint  set  descriptor 

NBS  Random  Access 

Constraint  set  identifier 

{iso  identif ied-organization 
oiw(14)  ftamsig(5)  constraint-set(4) 
nbs-random-access (2) } 

Node  names 

All  names  shall  be  of  the  same  type;  the 
type  of  the  names  and  an  ordering  of  the 
names  shall  be  defined  when  reference  is 
made  to  the  constraint  set. 

File  access  actions 

Locate,  Read,   Insert,  Erase,  Replace 

Qualified  actions 

None 

Available  access  context 

UA 

Creation  state 

Root  node  without  an  associate  data  unit 

Location  after  open 

Root  node 

Beginning  of  file 

Root  node 

End  of  file 

No  node  selected 

Read  whole  file 

Read  in  access  context  UA  with  FADU- 
Identity  of'begin" 

Write  whole  file 

Transfer  a  series  of  leaf  FADUs  which 
would  be  generated  by  reading  the  whole 
file  in  access  context  UA;     Perform  the 
transfer  with  an  FADU  Identity  of  "end" 
and  a  file  access  action  of  "insert,"  or 
with  an  FADU  Identity  of  "begin"  and  an 
action  of  "replace,"  or  with  an  FADU 
Identity  of  "node-number"  and  an 
action  of  "replace."    Here  "node 
number"  identifies  the  first  FADU  in  the 
preorder  traversal  sequence. 
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Table  10.7.     Identity  constraints  in  the  NBS  Random  Access  Constraint  Set 


Action 

Begin 

End 

NodeSeq 

Node  Number 

Locate 

leaf 

Read 

whole 

leaf 

Insert 

leaf 

Erase 

whole 

leaf 

Replace 

whole 

leaf 

Note:         NodeSeq  =  A  sequence  of  node  names  with  a  single  member 

1 .  Field  of  application 

The  NBS  Random  Access  constraint  set  applies  to  files  which  are  structured 
into  a  sequence  of  individual  FADUs  and  to  which  access  may  be  made  randomly 
by  NodeSeq.  The  structuring  of  the  file  into  individual  FADUs  is  determined 
by  the  NodeName . 

2 .  Basle  constraints 

The  basic  constraints  in  the  NBS  Random  Access  constraint  set  are  given  in 
table  10.6. 

3 .  Structural  constraints 

The  root  node  shall  not  have  an  associated  data  unit;  all  children  of  the 
root  node  shall  be  leaf  nodes  and  shall  have  an  associated  data  unit;  all 
arcs  from  the  root  node  shall  be  of  length  one. 

4.  Action  constraints 

Insert:  the  insert  action  is  allowed  only  at  the  end  of  the  file,  with 
FADU-Identity  of  "end";  the  new  node  is  inserted  following  all  existing 
nodes  in  the  file.     The  location  following  the  insert  is  "end." 

Erase:  the  erase  action  is  allowed  at  the  root  node  to  empty  the  file,  with 
FADU-Identity  of  "begin."  The  result  is  a  solitary  root  node  without  an 
associated  data  unit.  Erase  with  the  FADU-Identity  of  "node  number"  means 
truncation  of  the  file. 

Replace  whole  file:     the  FADU-Identity  is  "begin"  and  the  complete  series  of 
new  FADU  contents  is  sent. 

Replace  new  leaves:      the   FADU-Identity   is   "node  number"   and  the  number  of 
FADUs  being  replaced  is  given  by  the  number  of  FADUs  sent. 

5 .  Identity  constraints 

The    FADU-Identity    associated   with    the    file    action    shall    be    one    of  the 
identities:     begin,  end.  Node  Number  and  NodeSeq.     The  actions  with  which  ^ 
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APPENDIX  E: 


ABSTRACT  SYNTAXES 


E.l    NBS  Node  Name  Abstract  Syntax 

Abstract  Syntax  Name 

{  iso  identified-organlzation  oiw(14)  ftamsig(5)  abstract- syntax( 2) 
nbs-node-name(3)  ) 

"NBS  random  access  node  name  abstract  syntax" 

This  is  an  abstract  syntax  for  the  user-coded  Node-Name  in  the  FTAM 
FADU  abstract  syntax. 


(        starting- fadu  [0]  IMPLICIT  INTEGER, 
fadu- count  [1]  IMPLICIT  INTEGER  } 

--a  "fadu-count"  of  0  specifies  the 
--range  of  FADUs 

--beginning  at  "starting- fadu"  and 
--ending  at  "end  of  file" 


For  this  abstract  syntax  the  following  transfer  syntax  will  be  used, 

{  joint-iso-ccitt  asnl(l)  basic-encoding(l)  ) 
"Basic  Encoding  of  a  single  ASN.l  type" 

E.2    NBS  Random  Binary  Access  File  Abstract  Syntax 

Abstract  Syntax  Name 

{  iso  identif ied-organization  oiw(14)  ftamsig(5)  abstract- syntaxC 2) 
nbs-random-binary(4)  } 

"NBS  random  binary  access  file  abstract  syntax" 

This  is  an  abstract  syntax  for  the  transfer  of  the  file  contents  for 
NBS  Random  binary  files. 


NBS-AS3  DEFINITIONS: := 


BEGIN 


NBS-Node-Name: :=  SEQUENCE 


END 


NBS-AS4  DEFINITIONS: := 


BEGIN 


NBS -Random  Binary  : :=  OCTET  STRING 

--contains  one  or  more  presentation  data  values 
--concatenated  together. 

--Each  presentation  data  value  is  defined  as 
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--Datatypel  in  table  10.2. 

END 

For  this  abstract  syntax  the  following  transfer  syntax  will  be  used. 

{        j oint- iso-ccitt  asnl(l)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.l  type" 

I         E.3    NBS  Simple  Text  Abstract  Syntax 

Abstract  Syntax  Name 

{iso  identif ied-organization  oiw(14)  ftamsig(5) 
abstract- syntax( 2)  nbs- simple- text (5)  ) 
"NBS  simple  text  abstract  syntax" 

NBS-AS5  DEFINITIONS : := 

BEGIN 

NBS -Text: :=  CHOICE  { 

IA5String ,- -Universal  Class  22 
GraphicString ,- -Universal  Class  25 
VisibleString ,- -Universal  Class  26 
GeneralString- -Universal  Class  27 
) 

END 

For  this  abstract  syntax,   the  following  transfer  syntax  will  be  used: 

{ j oint- iso-ccitt  asnl(l)  basic-encoding( 1 ) ) 
"Basic  encoding  of  a  single  ASN.l  type" 
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11    DIRECTORY  SERVICES  PROTOCOLS 
11.1  INTRODUCTION 

This  is  an  Implementation  Agreement  developed  by  the  Implementor's  Workshop  sponsored 
by  the  National  Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of 
data  between  devices  manufcictured  by  different  vendors.  This  agreement  is  bcised  on  euid 
employs  protocols  developed  in  accord  with  the  OSI  Reference  Model.  While  this  agreement 
introduces  no  new  protocols,  it  eliminates  ambiguities  in  interpretations. 

This  is  an  Implementation  Agreement  for  the  OSI  Directory  based  on  the  ISO  and 
CCITT  documents  cited  in  the  Reference  section  19.2  (hereafter  referenced  as  Directory 
Documents).  This  agreement  is  aligned  with  the  UNOFFICIAL  'FINAL'  version  of  the 
X.500  Series  of  Recommendations,  December  1988.  Where  technicaJ  differences  between 
the  ISO  and  CCITT  versions  of  these  documents  exist  (e.g.,  Transport  Requirements)  the 
ISO  versions  are  given  precedence,  figure  11.1  displays  the  structure  of  this  Implementation 
Agreement.  References  to  corresponding  CCITT  documents  are  included  for  information. 


Directory  Access  Protocol 
(DAP) 


Directory  System  Protocol 
(DSP) 


Remote  Operations  Services  and  Protocols 
(CCITT  X.219  and  X.229/ISO  9072/1  and  9072/2) 


Association  Control  Services  and  Protocols 
(CCITT  X.217  and  X.227/ISO  8649  and  8650) 


Figure  11.1.  Structure  of  this  Implementation  Agreement. 

The  Directory  User  Agents  (DUAs)  and  Directory  System  Agents  (DSAs)  provide  access 
to  The  Directory  on  behalf  of  humans  and  applications  such  as  Message  Handling  and  File 
Transfer,  Access,  and  Management.  See  the  Scope  and  Field  of  Application  section  for  more 
information  on  the  model  used  in  the  Directory. 

This  document  covers  both  the  Directory  Access  Protocol  (DAP)  and  the  Directory 
System  Protocol(DSP)  defined  in  the  Directory  Documents.  A  good  working  knowledge  of 
the  Directory  Documents  is  assumed  by  this  chapter.  All  terminology  and  abbreviations 
used  but  not  defined  in  this  text  may  be  found  in  those  documents. 


11.2    SCOPE  AND  FIELD  OF  APPLICATION 

Centralized  and  distributed  directories  can  both  be  accorrunodated  in  this  Agreement  by  the 
appropriate  choice  of  protocols  and  pragmatic  constraints  from  those  specified.  Figure  11.2 
illustrates  a  centralized  directory  and  figure  11.3  illustrates  a  distributed  directory. 
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This  agreement  does  not  cover  interaction  between  co-located  entities,  such  as  a  co- 
resident DUA  and  DSA.  It  also  does  not  specify  the  interface  between  a  user  (person  or 
application)  and  a  DUA.  Bilateral  agreements  between  a  DUA  and  DSA  or  DSA  and  DSA 
may  be  implemented  in  addition  to  the  requirements  stated  in  this  document.  Conformance 
to  this  agreement  requires  the  ability  to  interact  without  the  use  of  bilateral  agreements 
other  than  those  required  in  the  Directory  Documents. 

The  logical  structure  of  the  Directory  Information  Base  (DIB)  is  described  in  the  Direc- 
tory Documents.  The  manner  in  which  a  local  portion  of  the  DIB  is  organized  and  accessed 
by  its  DSA  is  not  in  the  scope  of  this  agreement. 

11.3  STATUS 

This  version  was  completed  in  December  1989. 

11.4  USE  OF  THE  DIRECTORY 

Given  the  rapid  multiplication  and  expansion  of  OSI  applications,  telecommunication  sys- 
tems and  services,  there  is  growing  need  for  users  of  OSI  applications,  as  well  as  the  appli- 
cations themselves,  to  communicate  with  each  other.  In  order  to  facilitate  their  communi- 
cations, a  Directory  protocol,  as  referenced  in  these  agreements,  has  been  tailored  to  meet 
their  respective  needs. 

In  one  instance.  The  Directory  will  be  used  as  a  service  to  provide  humans,  in  an  on-line 
fashion,  rapid  and  easy  retrieval  of  information  useful  for  determining  what  telecommunica- 
tions services  are  available,  and/or  how  to  access,  and  address  their  correspondents.  Further, 
service  providers  offering  such  a  Public  Directory  may  also  use  this  service  internally  with 
other  various  telecommunications  services  (e.g.,  MHS)  for  the  proper  addressing  of  calls  or 
messages.  Likewise,  this  does  not  preclude  the  usage  of  these  agreements  to  similarly  gener- 
ate a  privately  operated  Directory  that  supports  both  human  and  application  information 
exchanges. 

In  another  instance.  The  Directory,  will  be  used  as  a  service  by  computer  applications 
without  direct  human  involvement.  One  important  service  is  to  provide  Presentation  Ad- 
dress resolution  for  named  objects,  on  behalf  of  OSI  applications.  The  Directory  may  be 
used  by  apphcations  to  search  for  objects  (i.e.,  Apphcation  Entities),  without  direct  human 
involvement,  by  the  use  of  the  "search"  or  "list"  operations. 

To  support  the  many  possible  usages,  The  Directory  is  a  general  purpose  system.  It 
is  capable  of  storing  data  of  many  different  forms  as  attributes  within  entries,  and  is  also 
capable  of  supporting  simple  or  complex  hierarchical  structures,  with  variations  in  structure 
possibly  occurring  between  one  part  of  The  Directory  and  another. 

Compliant  DSA  implementations  should  safeguard  this  generality,  where  possible,  by 
placing  the  minimum  of  restrictions  in  "hard-wired"  form. 


11-2 


December  '89 


fa      The  Directory 


USER 


USER 


DUA 


DUA 


DSA 


Figure  11.2.  Centralized  Directory  Model. 
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Figure  11.3.  Distributed  Directory  Model. 
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11.5  DIRECTORY  ASEs  AND  APPLICATION  CONTEXTS 

This  section  highlights  the  ASEs  (Application  Service  Elements)  and  Application  Contexts 
defined  in  the  Directory  Documents  and  of  concern  in  these  Agreements.  The  functionality 
of  the  Directory  AEs  (DUAs  and  DSAs)  is  defined  by  a  set  of  ASEs,  each  Directory  ASE 
specifying  a  set  of  Directory  operations. 

The  interaction  between  these  AEs  is  described  in  terms  of  their  use  of  ASEs.  This 
specific  combination  of  a  set  of  ASEs  and  the  rules  for  their  usage  defines  an  application 
context. 

The  following  ASEs  are  described  in  the  Directory  Documents: 

•  Read  ASE 

•  Chained  Read  ASE  , 

•  Search  ASE 

•  Chained  Search  ASE 

•  Modify  ASE 

•  Chained  Modify  ASE 

ROSE  and  ACSE  also  form  part  of  the  Directory  Application  Contexts. 
The  following  Application  Contexts  are  described  in  the  Directory  Document: 

•  Directory  Access  AppHcation  Context 

•  Directory  System  Application  Context 

11.6  SCHEMA 

There  are  seven  (7)  major  topics  that  relate  to  schema: 
11.6.1    Support  of  Structures  and  Naming  Rules 

DSAs  shall  be  capable  of  supporting  (subject  to  refinements  laid  down  in  these  Agreements) 
the  structure  and  naming  rules  defined  in  the  Directory  Documents,  Part  7,  Annex  B. 

Part  7,  Annex  B  of  the  Directory  Documents  provides  a  framework  for  the  basic  use  of 
the  Directory  in  terms  of  the  objects  defined  in  Part  7.  It  does  not,  however,  form  part  of 
the  standard  and,  in  any  case,  permits  structures  and  practices  which  may  be  undesirable. 
The  guidelines  below  provide  tighter  control  within  the  Annex  B  framework. 

It  is  recommended  that  only  an  entry  subordinate  to  Root  or  Country  may  use  a  State- 
OrProvinceName  AVA  as  an  RDN. 
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11.6.2  Support  of  Object  Classes  and  Subclasses 

The  DSAs  shall  be  able  to  support  all  superclasses  of  the  supported  object  classes  (e.g., 
Top,  Person). 

Use  of  an  object  class  in  this  profile  or  the  standard  (or  a  subclass  derived  from  one  or 
more  of  these  object  classes)  is  recommended  wherever  the  semantics  are  appropriate  for  the 
application.  The  derivation  of  a  new  object  class  as  an  immediate  subclass  of  Top  should 
be  avoided.  For  example,  to  represent  printers  in  the  Directory,  one  can  derive  a  subclass 
of  Device. 

An  entry  of  a  particular  object  class  may  contain  any  optional  attribute  Hsted  for  it  in 
the  Directory  Documents;  a  conformant  DSA  shall  be  able  to  support  all  these  optional 
attributes. 

In  addition,  a  DSA  may  permit  any  locally  registered  attribute,  or  a  subset  of  these, 
by  providing  the  local  extension  facilities  permitted  by  unregistered  object  classes  (viz. 
Directory  Documents,  Part  2,  clause  9.4.1  (a)  and  Note). 

11.6.3  Support  of  Attribute  Types 

DSAs  shall  be  able  to  support  the  storage  and  use  of  attribute  type  information,  as  defined 
in  the  Directory  Documents,  Part  6,  including  their  use  in  naming  and  access  to  entries; 
they  shall  also  support  the  definition  of  new  attribute  types,  making  use  of  pre-existing 
attribute  syntaxes. 

DSAs  shall  support  the  encoding,  decoding,  and  matching  of  all  the  attributes  in  the 
Naming  Prefixes  of  every  naming  context  they  hold  (ref  Directory  Documents,  Part  4,  clause 
9).  These  attributes  may  include  attributes  that  are  not  permitted  to  appear  in  entries  in 
those  naming  contexts. 

11.6.4  Support  of  Attribute  Syntaxes 

Suggested  methods  for  the  interpretation  of  selected  Attribute  Syntaxes  are  defined  in  Ap- 
pendix A. 

11.6.5  Naming  Contexts 

The  root  of  a  naming  context  shall  not  be  an  alias  entry. 

11.6.6  Common  Profiles 

This  section  identifies  profiles  that  are  commonly  useful  for  various  applications  while  an 
appUcation-specific  profile(s)  is  identified  by  the  application. 
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11.6.6.1    OIW  Directory  Common  Application  Directory  Profile 

11.6.6.1.1     Standard  Application  Specific  Attributes  and  Attribute  Sets 

The  attributes  and  attribute  sets  in  the  Directory  Document,  Part  6,  associated  with  the 
object  classes  Usted  below  are  required. 


11.6.6.1.2    Standard  Application  Specific  Object  Classes 


DSAs  shall  be  able  to  support  storage  and  use  of  the  object  classes  below,  as  defined  in  the 
Directory  Documents,  Part  7,  and  these  object  classes  are  expected  to  be  useful  for  a  range 
of  applications. 

The  following  object  classes  are  mandated  by  the  standard: 

Top  Alias 
DSA 


The  following  object  classes  are  expected  to  be  generally  useful  in  the  creation  of  the  upper 
portion  of  the  DIT: 


Country 
Locality 

Application  Process 


Organization 
Organizational  Unit 


The  following  object  classes  are  expected  to  be  generally  useful  in  the  creation  of  DIT  leaf 
entries: 


Alias 

Application  Process 
Application  Entity 
DSA 
Device 


Group  of  Names 
Organizational  Person 
Organizational  Role 
Residential  Person 


11.6.6.2     OIW  Directory  Strong  Authentication  Directory  Profile 
11.6.6.2.1     Other  Profiles  Supported 

This  profile  is  used  in  conjunction  with  the  OIW  Directory  Common  Application  Directory 
Profile. 
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11.6.6.2.2    Standard  Application  Specific  Object  Classes 

The  following  object  classes  are  expected  to  be  generally  useful  for  applications  to  support 
strong  authentication: 

•  Strong  Authentication  User 

•  Certification  Authority 

11.6.7    Restrictions  on  Object  Class  Definitions 

An  object  class  may  not  be  defined  as  a  subclass  of  itself,  as  the  chain  of  superclasses  of  such 
an  object  class  would  be  a  closed  loop,  isolated  from  all  other  object  classes,  specifically 
Top.  Such  isolation  is  clearly  illegal. 

11.7    PRAGMATIC  CONSTRAINTS 

This  section  describes  pragmatic  constraints  to  which  a  conformant  implementation  shall 
adhere  in  addition  to  those  specified  in  the  Directory  Documents.  The  pragmatic  con- 
straints can  be  divided  into  two  major  areas.  The  first  includes  those  aspects  of  pragmatic 
constraints  which  apply  to  scope  of  service  (see  sec.  11.7.1  and  sec.  11.7.2).  The  second 
includes  those  aspects  of  pragmatic  constraints  which  are  specific  to  particular  attribute 
types  (see  sec.  11.7.3). 

11.7.1    General  Constraints 

11.7.1.1  Character  Sets 

It  is  a  requirement  to  support  all  character  sets  and  other  name  forms  defined  in  the  Direc- 
tory Documents,  Part  6.  Those  character  sets  include: 

•  T.61 

•  PrintableString 

•  NumericString 

11.7.1.2  APDU  Size  Considerations 

In  the  process  of  chaining  requests  it  is  possible  that  a  chaining  DSA  may  receive,  invoke  or 
return  APDUs  that  exceed  its  capacity.  It  is  a  minimum  requirement  that  invoke  APDUs 
and  return  result  APDUs  shall  be  accepted  unless  they  exceed  .32767  octets  in  size;  in  this 
case  they  may  be  discarded  as  illustrated  in  the  right  side  of  figure  11.4  (page  11  -  8),  and 
an  "unwillingToPerform"  error  reporting  service  shall  be  used. 
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DSA  may  pass  on 


DSA  may  discard 


Figure  11.4.  APDU  Exchange. 


11.7.1.3  Service  Control  (SC)  Considerations 

This  agreement  recognizes  that  DUAs  may  automatically  supply  defaults  for  any  SC 
parameter.  The  choice  of  default  values  selected  (if  any)  is  seen  to  be  a  matter  of  local 
policy  and  consumer  needs. 

11.7.1.4  Priority  Service  Control 

Priority  is  specified  as  a  service  control  argument  in  the  Directory  Documents.  The 
following  statements  represent  a  clarification  of  the  semantics  that  may  be  used  by  a  DSA 
in  interpreting  and  operating  on  this  parameter. 

The  logical  model  in  figure  11.5  (  page  11-9)  may  be  considered  as  an  example  by 
DSAs  that  implement  this  Service  Control.  In  figure  11.5,  note  that: 

•  the  DSA  maintains  three  logical  queues  corresponding  to  the  three  priority  levels; 

•  the  DSA  Scheduler  is  separate  and  distinct  from  any  scheduling  function  provided  by 
the  underlying  operating  system  or  control  program  services; 

•  the  DSA  Scheduler  presents  jobs  to  the  Underlying  Operating  Services  for  execution 
and  always  presents  jobs  of  a  higher  priority  before  those  of  a  lower  priority; 

•  the  DSA  Scheduler  will  not  preempt  a  request  once  it  has  been  passed  to  the  underlying 
operating  system  service. 

11.7.2    Constraints  on  Operations 

There  are  no  overall  constraints  upon  service  arguments  or  results  except  those  implied  in 
section  11.7.1.2  of  this  document. 

11.7.2.1  Filters 

It  is  required  that  DSAs,  at  a  minimum,  support  8  nested  "Filter"  parameters,  and  a  total 
limit  of  32  Filter  Items.  If  these  hmits  are  exceeded,  the  recipient  of  that  SearchArgument 
may  return  the  ServiceProblem  "unwillingTo Perform" . 
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Figure  11.5.  Logical  DSA  Application  Environment. 

11.7.2.2  Errors 

There  are  no  constraints  upon  any  Error  service  except  the  APDU  size  limit  as  defined  in 
Section  11.7.1. 


11.7.2.3    Error  Reporting  -  Detection  of  Search  Loop 

A  search  operation  may  encounter  a  looping  situation  when  the  search  encompasses  "whole- 
subtree",  and  an  alias  is  encountered  which  is  a  superior  to  some  other  subtree  that  has 
been  encountered  during  the  search. 

DSAs  should  be  able  to  detect  this  situation.  One  possible  method  is  by: 

1.  Maintaining  a  list  of  the  base  objects  of  searches  initiated  as  a  consequence  of  Step  5 
of  Part  4,  clause  18.7.2.2.1  of  the  Directory  Documents  (this  may  require  an  analysis 
of  the  Tracelnformation  field). 

2.  Determining  whether  a  new  base  object  is  superior  to  any  base  object  on  this  list. 

A  new  base  object  which  would  cause  a  loop  in  this  way  should  be  discarded  (i.e.  should 
not  cause  a  new  search),  but  no  error  should  be  reported  by  an  error-reporting  service.  The 
circumstances  should  be  logged  so  that  it  may  be  reported  to  an  appropriate  Administrative 
Authority  for  rectification. 


11.7.3    Constraints  Relevant  to  Specific  Attribute  Types 

Table  11.1  (  pages  11  -  36  and  11  -  37)  gives  pragmatic  constraints  associated  with  selected 
attribute  types  specified  in  the  Directory  Documents;  many  of  these  constraints  also  appear 
and  are  the  same  in  the  CCITT  version  of  the  Directory  Documents.  Each  constraint  in 
Table  11.1  is  given  in  terms  of  a  length  constraint.  The  length  constraint  for  a  given  attribute 
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value  is  the  number  of  units  which  a  sending  entity  shall  not  exceed  and  which  a  receiving 
entity  shall  accept  and  process.  A  sending  entity  need  not  be  capable  of  sending  attribute 
values  as  large  as  the  length  constraints. 

Note  that  in  table  11.1  the  length  constraint  for  strings  is  expressed  as  the  number  of 
allowable  characters. 

In  addition  to  the  constraints  given  in  table  11.1,  the  following  constraints  apply  to 
alphabets  and  integer  values. 

•  Alphabets:  T.61  Strings  used  as  attribute  values  shall  only  encode  graphic  characters 
and  spaces.  They  shall  not  contain  formatting  characters  (such  as  subscript)  or  other 
control  characters. 

•  Integer  Values:  DSAs  shall  be  required  to  "pass  through"  encoded  integer  attribute 
values  of  arbitrary  length  (e.g.,  when  chaining  a  Directory  operation).  No  Directory 
component  (i.e.,  DUA  or  DSA)  shall  be  deemed  non-conformant  if  it  encodes  integer 
attribute  values  of  arbitrary  length. 

Components  of  the  Directory  are  required  to  support  (for  storage  and  processing),  as 
a  minimum,  integer  attribute  values  encoded  in  4  octets. 


11.8  CONFORMANCE 

The  following  sections  will  describe  various  aspects  of  Directory  conformance.  It  should 
be  noted  that  conformance  to  the  various  ASEs  and  conformance  to  the  Authentication 
Framework  are  viewed  as  separate  issues  and  are  presented  in  that  context. 

11.8.1    DUA  Conformance 

Conformance  requirements  for  DUAs  are  adequately  specified  in  the  Directory  Documents, 
Part  5,  clause  9.1  and  the  Directory  Access  Profile  (see  sec.  11.8.6).  It  should  be  noted 
that  the  DUA  conformance  is  based  on  DAP  Protocol  and  not  the  User  Interface.  Not  all 
options  available  in  the  standard  need  to  be  made  available  to  the  user  of  the  DUA. 

It  is  recognized  that  DUAs  will  be  widely  differing  in  nature: 

•  Some  are  intended  to  support  human  users,  some  application  users 

•  Particular  DUAs  may  not  support  particular  operations  because  the  application  that 
they  support  has  no  requirement;  others  will  be  general  purpose,  and  will  support  all 
operations. 

•  Some  DUAs  will  have  a  fixed  view  of  the  Directory  content  and  structure,  reflecting 
the  usage  of  The  Directory  by  a  particular  application;  others  will  have  a  more  flexible 
view  which  can  be  adapted  to  new  usages. 

•  Some  DUAs  will  provide  automatic  referral  services  with  automatic  establishment  and 
release  of  associations;  others  will  place  the  burden  on  the  user. 
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•  Some  DUAs  will  provide  a  variety  of  authentication  means;  others  will  support  no 
authentication 

•  Some  DUAs  will  handle  operations  synchronously;  others  will  have  the  capability  of 
maintaining  several  identifiable  dialogues  with  The  Directory  at  one  time. 

In  the  next  section,  different  types  of  DSAs  are  discussed.  The  DUA  is  independent  of 
the  type  of  DSA  it  is  communicating  with  and  does  not  need  to  know  what  type  of  DSA  it 
is  communicating  with. 

11.8.2  DSA  Conformance 

Basic  conformance  requirements  for  a  DSA  are  defined  in  the  Directory  Documents,  Part  5, 
clause  9.2.  Some  of  the  terms  used  to  describe  DSA  conformance  are  summarized  below. 

•  Centralized:  A  centralized  DSA  is  defined  as  one  that  contains  its  entire  relevant  DIT; 
it  follows  that  it  will  not  make  use  of  the  DSP  or  generate  referral  responses.  Since 
this  model  only  contains  a  single  DSA  it  is  not  subject  to  DSA  interworking  issues 
and  will  always  provide  a  consistent  level  of  service  and  results.  A  centralized  DSA 
shall  be  fully  "protocol"  conformant  to  the  DAP. 

•  Cooperating:  In  a  distributed  directory,  responsibility  for  various  portions  of  the  DIT 
may  be  "distributed"  among  multiple  DSAs.  On  a  per  operation  basis  we  define  a 
DSA  to  be  holding  when  it  is  responsible  for  the  fragment  of  the  DIB  in  which  a  given 
entry  will  appear  if  it  exists;  we  define  a  DSA  to  be  propagating  when  it  is  unable  to 
complete  the  name  resolution  process. 

All  DSAs  shall  be  capable  of  acting  as  a  holder  and  a  propagator. 

11.8.3  DSA  Conformance  Classes 

A  DSA  implementation  shall  satisfy  the  conformance  requirements  as  defined  in  the  Direc- 
tory Documents,  Part  5,  section  9.2,  and  shall  support  the  "Versions"  argument  of  "Bind". 

Per  the  conformance  section  of  the  Directory  Documents,  a  DSA  shall  conform  to  the 
abstraxrt  syntax  of  the  attribute  types  for  which  conformance  is  claimed.  These  attribute 
types  shall  include  those  required  by  section  11.6.3  of  this  Implementor's  Agreement. 

Additionally,  an  implementation  conformant  to  these  agreements  shall  state  which  of  the 
following  conformance  classes  it  implements: 

•  Conformance  Class  0  -  Centralized  DSA 

A  DSA  conformant  to  this  class  only  supports  the  DirectoryAccessAC. 

As  the  performance  of  Search  and  List  operations  can  consume  significant  resources, 
the  policies  of  some  centralized  DSAs  may  be  such  that  these  operations  will  not 
be  performed.  For  these  cases,  the  reply  to  requests  for  such  operations  would  be  a 
ServiceError  with  the  "unwillingToPerform"  ServiceProblem. 


11  -  11 


December  '89 


•  Conformance  Class  1  -  Distributed  DSA 

A  DSA  implementation  conformant  to  this  class  shall  implement  all  the  operations  in 
the  ASEs  that  are  part  of  the  Application  context  for  which  it  claims  conformance.  It 
shall  support  the  DirectoryAccessAC  and  it  may  optionally  support  the  DirectorySys- 
temAC. 

DSAs  conformant  to  these  Agreements  shall  support  the  OIW  Directory  Common  Appli- 
cation Directory  Profile.  In  addition,  DSAs  may  optionally  conform  to  the  OIW  Directory 
Strong  Authentication  Directory  Profile.  Future  versions  of  these  Agreements  may  allow 
additional  possibilities  for  minimal  profile  conformance. 

11.8.4    Authentication  Conformance 

A  Directory  System  may  choose  to  implement  various  levels  of  authentication  (Directory 
Documents,  Part  8).  We  define  the  following  levels  of  authentication  in  the  DS: 

•  No  authentication  at  all;  (None) 

•  Simple  Uncorroborated:  identification  without  verification 

•  Simple  Uncorroborated  authentication  with  verification:  verified  identification 
without  a  password. 

•  Simple  Corroborated  authentication:  verified  identification  with  a  password;  in- 
tended to  make  masquerading  difficult. 

•  Strong  authentication:  identification  with  verification  using  cryptographic  techniques 
intended  to  make  masquerading,  in  practical  terms,  nearly  impossible. 

The  "Authentication  Framework"  document  describes  the  specific  goal  of  each  authen- 
tication level;  listed  below  are  several  practical  uses  of  the  various  levels.  ^ 

Simple  Uncorroborated  authentication  may  be  desired  to  maintain  access 
statistics  or  in  a  private  network  where  the  initiator  is  implicitly  trusted  and  there 
is  no  need  to  incur  the  additional  overhead  of  more  sophisticated  authentication 
methods. 

Simple  Corroborated  authentication  may  be  necessary  in  situations  where 
strong  authentication  is  not  practical,  (i.e.,  international  connection,  no  knowl- 
edge of  algorithms  in  use,  etc). 

Strong  authentication  will  be  required  for  secure  environments. 

A  DSA  that  implements  Simple  Corroborated  authentication  will  check  the  user  pass- 
word by  means  of  a  compare  operation  on  the  user's  entry.  If  no  user  password  is  supplied 
(Simple  Uncorroborated  authentication)  the  DSA  will  validate  the  presence  of  the  entry  for 

^  It  is  the  case  that  some  DSAs  containing  public  information  may  not  require  authentication. 
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the  user,  by  a  read  operation  or  otherwise.  The  authentication  will  fail  if  the  password  is 
incorrect  or  if  the  user's  entry  does  not  exist. 

A  DSA  that  implements  Simple  Uncorroborated  authentication  without  verification  will 
accept  simple  credentials  without  validating  them. 

Implementations  claiming  conformance  shall,  as  a  minimum,  implement  None  and  Sim- 
ple Uncorroborated  authentication  without  verification. 

11.8.5    Directory  Service  Conformance 

The  following  sections  will  describe  various  aspects  of  Directory  conformance.  Conformance 
to  the  Authentication  Framework  is  viewed  as  a  separate  issue  from  conformance  to  the  rest 
of  the  Directory  document  and  is  presented  in  that  context. 

Directory  Profiles  are  broken  into  two  sections.  Service  support  specifies  the  level  of 
support  for  operations  and  errors.  Protocol  support  specifies  the  protocol  elements  required 
for  implementations  which  claim  conformance  to  specified  operations. 

To  specify  the  support  for  operations  and  errors,  two  classifications  are  used  as  follows. 

1.  r:  required 

The  operation  shall  be  implemented  and  the  respective  error  shall  be  handled  for 
conformance  to  these  agreements. 

For  DUAs,  required  means: 

•  For  ARGUMENT  parameters,  create  the  DAP  protocol  elements  to  convey  the 
service  request  to  the  DSA. 

•  For  RESULT  and  ERROR  parameters,  accept  the  DAP  protocol  elements. 
For  DSAs,  required  means: 

•  For  ARGUMENT  parameters,  accept  the  protocol  elements  when  received  and 
create  the  protocol  elements  when  acting  as  a  requesting  DSA. 

•  For  RESULT  and  ERROR  parameters,  be  able  to  convey  all  possible  results 
when  responding  in  either  the  DAP  or  DSP  protocols  and  when  receiving  results, 
perform  additional  processing  as  defined  for  cooperating  DSAs. 

2.  n:  not  required 

It  is  left  to  implementations  as  to  whether  the  operation  or  error  is  implemented  or 
not. 

To  specify  the  support  for  protocol  elements,  four  classifications  are  used  as  follows. 
1.  M:  mandatory 

Generation  of  element  is  a  mandatory  static  conformance  requirement  (i.e.,  a  confor- 
mant implementation  shall  be  capable  of  generating  the  element). 

Generation  of  element  is  a  mandatory  dynamic  conformance  requirement  (i.e.,  the 
element  shall  be  present  in  all  instances  of  communication  which  use  the  element). 
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The  terms  static  conformance  and  dynamic  conformance  are  defined  in  ISO  9646-1, 
"OSI  Conformance  Testing  Methodology  and  Framework,  Part  1:  General  Concepts." 

2.  G:  generate 

Generation  of  element  is  a  mandatory  static  conformance  requirement. 

Generation  of  element  is  a  conditional  dynamic  conformance  requirement;  the  condi- 
tion is: 

Where  a  DSA  is  a  propagating  DSA,  it  shall  be  capable  of  generating  the 
protocol  element  as  received  in  related  APDUs  received  from  other  DSAs. 
Where  the  DSA  is  a  holding  DSA,  it  shall  be  capable  of  creating  all  possible 
values  of  a  protocol  element  unless  otherwise  noted  in  the  "Comments"  hne. 

3.  S:  support 

When  receiving  protocol  elements,  implementations  of  these  agreements  shaJl  be  ca- 
pable of  accepting  these  elements  without  error.  Actions  specified  in  the  Directory 
documents  and  in  these  agreements  shall  be  taken. 

4.  O:  optional 

When  generating  protocol  elements: 

•  Generation  of  element  is  an  optional  static  conformance  requirement.  If  the 
implementor  claims  support  for  the  corresponding  Directory  capability,  then  the 
implementation  shall  be  capable  of  generating  the  element. 

•  Generation  of  element  is  an  optional  dynamic  conformance  requirement.  If  the 
implementor  claims  support  for  the  corresponding  Directory  capability,  then  the 
element  shall  be  present  in  instances  of  communication  which  use  the  element 
(except  where  defaults  allow  otherwise). 

When  receiving  protocol  elements,  implementations  of  these  agreements  shall  be  capa- 
ble of  accepting  these  elements  without  error.  However,  actions  specified  in  the  base 
standard  and  in  these  agreements  may  be  taken  but  are  not  required. 

Where  protocol  elements  are  nested,  the  classification  of  the  nested  protocol  elements  is 
of  relevance  only  when  the  immediately  containing  protocol  element  is  generated.  The 
classification  of  the  protocol  elements  at  the  highest  level  is  relative  with  respect  to  support 
of  the  operation. 

Also  note  that  in  table  11.3,  some  rows  contain  two  support  classifications  in  the  DSA 
column.  In  such  cases,  the  support  classification  in  parentheses  applies  to  centralized  DSA's 
only.  When  there  is  only  one  support  classification  given,  it  applies  equally  to  centralized 
and  non-centrahzed  DSA's. 

11.8.6    The  Directory  Access  Profile 

This  agreement  requires  implementations  of  the  DUA  to  provide  access  to  the  Directory 
Services  as  defined  in  the  DUA  column  in  table  11.2.  For  the  services  in  table  11.2  which 
are  supported,  these  agreements  further  require  DUAs  to  support  the  protocol  elements  as 
defined  in  the  DUA  column  in  table  11.3  (parts  1  -  7). 
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These  agreements  require  implementations  of  the  DSA  to  support  the  Directory  Services 
as  defined  in  the  DSA  column  in  table  11.2  (page  11  -  40).  These  agreements  further 
require  DSAs  to  support  the  protocol  elements  as  defined  in  the  DSA  column  in  table  11.3. 
Table  11.3  is  listed  in  seven  parts  (page  11-41  through  page  11  -  47).  Note  that  the 
requirements  for  a  centralized  DSA  and  a  cooperating  DSA  are  different. 

11.8.7  The  Directory  System  Profile 

These  agreements  require  implementations  of  distributed  DSAs  which  provide  DSP  to  sup- 
port the  responder  role  for  services  as  defined  in  table  11.4  (page  11  -  48).  Further,  these 
agreements  require  DSAs  to  support  the  protocol  elements  as  specified  in  table  11.5.  Ta- 
ble 11.5  is  listed  in  nine  parts  (page  11-49  through  page  11  -  57). 

DSAs  are  required  to  support  the  requestor  role  for  all  the  services  as  defined  in  table  11.4 
if  conforming  to  the  chained  mode  of  interaction. 

11.8.8  Digital  Signature  Protocol  Conformance  Profile 

Table  11.6  on  page  11-58  and  table  11.7  on  page  11-58  provide  information  on  the  digital 
signature  protocol  conformance  profile. 

Note  that  elements  in  CommonArguments  and  CommonResults  SecurityParameters  that 
are  not  specified  in  table  11.6  and  table  11.7  are  covered  in  the  Directory  Service  Protocol 
Support  (table  11.5)  and  Directory  Access  Protocol  Support  (table  11.3). 

11.8.9  Strong  Authentication  Protocol  Conformance  Profile 

table  11.8  on  page  11-59  and  table  11.9  on  page  11-60  provide  information  on  the  strong 
authentication  protocol  conformance  profile. 

11.9    DISTRIBUTED  OPERATIONS 

The  following  requirements  apply  to  DSAs  supporting  distributed  operations: 

DSAs  supporting  authentication  (e.g.,  simple  authentication  by  name  and  pass- 
word) shall  be  able  to  invoke  DSP  operations  to  carry  out  authentication  by 
reference  to  other  DSAs.  Thus  all  such  DSAs  shall  support  the  DSP  protocol. 
The  requirement  is  implied  by  the  Directory  Documents. 

11.9.1    Referrals  and  Chaining 

It  is  recommended  that  a  DSA  which  has  chained  a  request  act  upon  any  referrals  it  receives 
rather  than  returning  them  to  the  requestor  if  the  "prefer Chaining"  service  control  is  present. 
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11.9.2    Trace  Information 

A  Tracelnformation  vaJue  carries  forward  a  record  of  the  DSAs  which  have  been  involved  in 
the  performance  of  an  operation.  It  is  used  to  detect  the  existence  of,  or  avoid,  loops  which 
might  arise  from  inconsistent  knowledge  or  from  the  presence  of  alias  loops  in  the  DIT. 

Each  DSA  which  is  propagating  an  operation  to  another,  adds  a  new  item  to  the  trace 
information.  If  the  propagation  of  a  Search  operation  involves  the  creation  of  a  new  Search 
(cf  Directory  Documents,  Part  4,  clause  18.7.2.2.2),  the  trace  information  shall  not  be  re- 
set, but  the  full  trace  information  for  the  overall  Search  operation  to  the  point  where  the 
new  Search  was  generated  shall  be  included  in  the  new  Search. 

11.10  UiNDERLYING  SERVICES 

This  section  specifies  requirements  over  and  above  those  given  in  the  Directory  Documents. 

11.10.1  ROSE 

It  should  be  noted  that  support  of  "abandon"  implies  support  of  operation  class  2. 

11.10.2  Session 

All  directory  implementations  are  required  to  support  Session  Version  2. 

11.10.3  ACSE 

The  A-ABORT  service  is  required  by  association-accepting  DSAs  to  escape  unwanted  associ- 
ations, which,  under  the  ROSE  protocol,  they  cannot  release.  In  all  other  cases  (association- 
initiating  DSAs  and  DUAs)  it  may  be  preferable  (though  not  required)  to  escape  associations 
using  UNBIND  rather  than  abort. 

The  aborting  DUA  or  DSA  may  optionally  use  the  user  information  field  of  the  A- 
ABORT.  Such  information,  however,  is  only  meaningful  for  diagnostic  purposes  and  its  use 
is  not  covered  by  these  Agreements. 

11.11  ACCESS  CONTROL 

Guidelines  relating  to  access  control  can  be  found  in  Annex  F  of  the  Directory  Documents, 
Part  2. 

11.12  TEST  CONSIDERATIONS 

This  section  outHnes  some  items  that  implementors  may  wish  to  consider  in  terms  of  testing 
expectations;  additionally,  future  conformance  testers  may  wish  to  consider  these  items 
when  developing  tests. 
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11.12.1  Major  Elements  of  Architecture 

One  important  aspect  of  testing  is  to  confirm  the  correct  behavior  of  DSAs  and  DUAs  with 
respect  to  major  elements  of  the  directory  architecture. 

Such  major  elements  include: 

•  Conformance  Statement 

•  Distinguished  names  (e.g.,  name  resolution,  equivalence  of  various  forms) 

•  Entries  and  Attributes  (e.g.,  accessibility  by  operations,  compliance  with  rules) 

•  Handling  of  distributed  operations  (e.g.,  naming  contexts  and  knowledge) 

•  Schemas 

—  Structure  rules  (e.g.,  storage  and  maintenance  of  structure  and  of  naming  rules) 

—  Object  classes  and  sub-classes  (e.g.,  storage  and  extension  of  rules  for  object 
attributes) 

—  Attribute  types  (e.g.,  storage  and  maintenance  of  syntax  classes  and  rules  for 
multi  or  single  valued  attributes) 

—  Attribute  syntax  (e.g.,  maintenance  and  support  for  attribute  value  testing  and 
matching,  to  specification  for  a  defined  set  of  attribute  types) 

•  Operations 

—  all  operations 

—  correct  function 

—  correct  result 

—  correct  responses 

•  Aliases  (e.g.,  correct  resolution,  error  responses) 

•  Authentication  and  Access  Control  (e.g.,  limitation  of  modify  access) 

•  ROSE  (e.g.,  correct  handling  of  invokes,  results,  rejects,  and  invoke  ids) 

•  ACSE  (e.g.,  association  establishment  /  refusal  for  invalid  application  contexts,  etc.) 

11.12.2  Search  Operation 

Testing  of  support  for  filter  items  should  be  reasonable.  It  is  not  expected  that  DSAs  will 
be  able  to  handle  worst  case  testing  in  this  area. 

11.13  ERRORS 

This  section  provides  clarification  of  the  semantics  of  various  operation  errors  and  imple- 
mentation guidelines  on  their  usage. 
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11.13.1  Permanent  vs.  Temporary  Service  Errors 

This  section  provides  some  clarification  regarding  the  usage  of  the  Service  Errors  busy, 
unavailable,  and  unwillingToPerform. 

The  error  busy  is  particularly  transient.  It  is  returned  when  one  or  more  of  The  Direc- 
tory's internal  resources  are  being  used  to  their  capacity  and,  hence,  the  requested  operation 
cannot,  for  the  moment,  be  performed.  The  Directory  should  be  able  to  recover  from  this 
type  of  resource  depletion  after  a  short  while. 

The  error  unavailable  is  also  temporary  but  somewhat  less  transient.  It  indicates  that 
The  Directory  (or  some  part  of  it)  is  currently  unavailable  and  may  continue  to  be  un- 
available for  a  reasonably  long  period  of  time.  For  example,  this  error  is  returned  when 
a  given  DSA  is  functionally  disabled,  or  when  a  specific  part  of  the  DIB  is  undergoing 
reconfiguration. 

The  error  unwillingToPerform  has  a  permanent  connotation.  It  indicates  that  The  Di- 
rectory cannot  perform  the  requested  operation  because  it  would  require  resources  beyond 
its  capacity.  For  example,  this  error  may  be  returned  by  a  DSA  if  satisfying  a  request  would 
result  in  the  generation  of  an  APDU  in  excess  of  32767  octets. 

11.13.2  Guidelines  for  Error  Handling 

11.13.2.1  Introduction 

This  subsection  provides  a  recommended  mapping  of  error  situations  which  may  be  encoun- 
tered to  ROSE  Rejects  or  to  the  errors  provided  in  the  DAP  and  DSP  protocols  of  the 
Directory  Documents. 

The  Directory  Documents  are  not  adequately  definitive  about  the  handling  of  errors.  In 
this  document,  more  exphcit  guidehnes  are  given. 

Error  situations  are  defined  by: 

•  Symptom  (i.e.,  the  manner  in  which  the  error  was  detected). 

•  Situation  (i.e.,  the  circumstance  or  phase  during  which  the  error  was  detected.  For 
each  possible  situation,  the  error-handling  procedure  needs  to  be  defined). 

11.13.2.2  Symptoms 

Table  11.10  (page  11  -  61  to  page  11  -  63)  describes  a  set  of  symptoms;  the  set  is  not 
necessarily  exhaustive.  Each  is  identified  by  a  title  which  is  used  later  in  describing  error 
actions.  The  title  used  for  each  symptom  is  not  intended  to  imply  any  particular  usage  in 
a  particular  implementation. 

11.13.2.3  Situations 

Table  11.11  (page  11-64)  identifies  recognized  situations  within  which  particular  symp- 
toms may  give  rise  to  distinct  error  actions. 
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11.13.2.4  Error  Actions 

Table  11.13  (page  11  -  66  to  page  11  -  71)  summarizes  specific  error  actions  for  each 
possible  combination  of  symptom  and  situation.  Symptoms  are  described  in  section  11.13.2.2 
and  situations  are  described  in  section  11.13.2.3. 

Each  entry  in  table  11.13  corresponds  to  the  symptom  in  the  left-most  column  and  the 
situation  given  in  the  column  header.  Each  entry  may  specify: 

•  a  specific  error  action.   The  error  action  is  described  using  the  notation  shown  in 
table  11.12. 

•  a  specific  error  action  and  a  relevant  note.  The  note  will  be  indicated  by  a  number 
enclosed  in  parentheses.  The  notes  can  be  found  on  page  11  -  72. 

•  only  a  relevant  note. 

•  a  blank  (which  indicates  the  corresponding  combination  of  symptom  and  situation  is 
not  meaningful  in  the  context  of  these  Agreements). 

The  entries  in  table  11.13  which  specify  a  specific  error  action  will  do  so  using  the 
notation  shown  in  table  11.12  (page  11  -  65). 

11.13.2.5  Reporting 

In  addition  to  the  use  of  error-reporting  services,  DSAs  should  implement  logging  ser- 
vices to  assist  in  management  of  the  Directory.  The  list  below  describes  classes  of  error 
which  should  be  logged.  Note  that  the  list  is  not  necessarily  complete. 

1.  Errors  indicating  attempted  breaches  of  security. 

2.  Errors  indicating  local  software  or  hardware  malfunction. 

3.  Errors  indicating  malfunction  or  other  unacceptable  behavior  on  the  part  of  the  invoker 
of  an  operation. 

4.  Errors  indicating  loss  of  chaining  service  by  another  DSA. 

5.  Error  conditions  that  would  be  difficult  to  diagnose  with  the  level  of  detail  supplied 
over  the  protocol. 

6.  Aborts  and  other  exceptional  communications  events. 

The  form  and  accessibihty  of  any  such  logs  is  for  further  study. 

11.14    Specific  Authentication  Schemes 

This  section  describes  identified  authentication  algorithms.  Use  of  algorithms  in  this  section 
is  not  mandatory.  Use  of  algorithms  other  than  those  described  in  this  section  or  described 
in  the  Directory  Documents  is  by  bilateral  agreement. 
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11.14.1    Specific  Strong  Authentication  Schemes 

This  section  provides  information  on  one  alternative  to  the  RSA  digitcJ  signature  scheme. 
The  alternative  is  identified  as  the  "ElGamal"  digital  signature  scheme.  Future  contributions 
may  result  in  other  alternatives  being  added  to  this  section. 

Implementors  may  choose  to  provide  digital  signature  capabihty  based  on  RSA,  ElGamal, 
or  some  other  scheme  appropriate  for  use  in  the  OSI  Directory  environment. 

It  should  be  noted  that  use  of  RSA  is  governed  by  U.S.A.  patent  law. 

11.14.1.1  ElGamal 

The  information  in  this  section  includes  a  tutorial  description  of  the  ElGamal  scheme 
for  digital  signature  using  the  notation  defined  in  the  Directory  Documents,  Part  8.  It  is 
intended  that  much  of  the  tutorial  information  provided  in  this  section  will  be  moved  to  the 
security  agreements  sometime  in  the  future. 
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11.14.1.1.2  Background 

The  ElGamal  digital  signature  scheme  is  based  on  earlier  work  done  by  Diffie  and  Hellman 
[DIFF76]  in  which  it  was  suggested  that  a  likely  candidate  for  a  one-way  function  is  the 
discrete  exponential  function 

f{x)  =        (mod  p)  (1) 

where  x  is  an  integer  between  1  and  p—  1  inclusive,  where  p  is  a  very  large  prime  number,  and 
where  a  is  an  integer  such  that  1  <  a  <  p  and  {a  mod  p,  mod  p,  •  ■  • ,  a''"^  mod  p}  is  equal 
to  the  set  {1, 2,  •  •  •  ,p  —  1}.  In  algebraic  terminology,  such  an  a  is  called  a  primitive  element. 
References  on  the  topic  of  primitive  roots  and  elements  are  [McC179]  and  [PATT87]. 

Now,  in  the  real  number  system,  if  y  =  a^,  then  by  definition  of  the  logarithm  we  can 
solve  for  x  using  x  =  logj^(y).  The  same  idea  extends  to  solving  eq  (1)  for  x  so  that  inverting 
f{x)  requires  calculating  discrete  logarithms.  The  reason  Diffie  and  Hellman  suspected  eq 
(1)  is  one-way  is  that  for  suitable  p,  it  is  computationally  difficult  to  invert  f{x).  According 
to  the  current  state  of  the  art,  computing  discrete  logs  for  suitable  p  has  been  found  to 
require  a  number  of  operations  roughly  equivalent  to 

exp(Vc6b6)  (2) 

where  b  is  the  number  of  bits  in  p,  and  c  is  estimated  at  c  =  .69  according  to  [ODLY].  This 
can  be  compared  to  only  about  2  log2  p  multipUcations  for  discrete  exponentiation.  If  in  fact 
the  best  known  algorithm  for  computing  discrete  logs  is  near  optimal  then  Expression  (2) 
is  a  good  measure  of  the  problem's  complexity  (for  a  properly  chosen  p)  and  the  discrete 
exponential  function  has  all  the  qualities  of  a  one-way  function  as  described  by  Diffie  and 
Hellman. 


11.14.1.1.3    Digital  Signature 

•  Private  Key:  Xs  denotes  the  private  key  for  user  X.  Xs  is  a  randomly  chosen  integer 
which  user  X  keeps  secret. 

•  Public  Key  :  Xp  denotes  the  public  key  for  user  X  and  is  calculated  using  the  corre- 
sponding private  key  such  that 

Xp  =  a^s    (mod  p)  (3) 

where 

—  p  is  a  prime  satisfying  the  requirements  listed  in  section  11.14.1.1.5. 

—  a  is  a  primitive  element  mod  p. 

—  Note  that  p  and  a  could  be  used  globally,  but  because  they  should  be  easily 
changeable  (see  sec.  11.14.1.1.5  for  information  about  why  these  two  parameters 
should  be  easily  changeable)  it  would  probably  be  preferable  for  each  user  to 
choose  his/her  own  p  and  a.  If  users  choose  their  own,  then  p  and  a  must  be 
made  available  to  the  recipient  for  use  in  the  signature  verification  process. 

•  Signing  Procedure:  Suppose  user  A  wants  to  sign  a  message  intended  for  recipient  B. 
The  basic  idea  is  to  compute  a  two  part  signature  (r,  s)  for  the  message  m  such  that 

a''^"'^  =  {ApYr'    (modp)  (4) 
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where  /i  is  a  one-way  hash  function. 
Compute  the  signature  (r,s)  as  follows. 

1.  Choose  a  random  number  k,  uniformly  between  0  and  p-1  such  that  k  and  p-1 
have  no  common  divisor  except  1  (i.e.,  gcd(fe,p—  1)  =  1). 

2.  Compute  r  such  that 

r  =  a*    (mod  p)  (5) 

3.  Use  r  to  solve  for  the  corresponding  s  as  follows. 

(a)  rewrite  eq  (4)  using  eq  (5)  and  the  definition  of  the  public  key  to  get 

Combining  exponents,  get 
eq  (7)  implies  that 

h{m)  =  {As)r  +  ks    (mod  p-1)  (8) 

Note  that  eq  (8)  has  a  single  solution  for  s  because  k  was  chosen  such  that 
gcd(ib,p-  1)  =  1.  See  [SIER88]  for  supporting  theorem. 

(b)  now  solve  for  s  and  get 

s  =  I{h{m)  -  {As)r)    (mod  p-1)  (9) 

where  /  is  computed  such  that  k  *  I  =  1    (mod  p  —  1). 
The  ElGamal  signature  is  comparable  in  size  to  the  corresponding  RSA  signature. 

11.14.1.1.4  Verification 

The  recipient  receives  Ap,m,r,s,a,  and  p  and  computes  both  sides  of  eq  (4)  and  then 
compares  the  results. 

11.14.1.1.5  Known  Constraints  on  Parameters 

The  following  list  of  constraints  is  the  result  of  a  search  of  current  literature  and  may  not 
be  complete. 

1.  p  must  be  prime 

2.  p  must  be  large. 

Note  that  Expression  (2)  can  be  used  to  speculate  on  the  level  of  security  afforded  by 
cryptosystems  based  on  the  discrete  log  problem.  Breaking  the  ElGamal  scheme  has 
not  been  proven  to  be  equivalent  to  finding  discrete  logs,  but  if  we  assume  equivalence 
then  we  can  estimate  how  large  p  should  be  for  a  desired  level  of  security. 

For  instance,  suppose  we  wanted  to  use  Expression  (2)  to  decide  how  large  p  should 
be  so  that  we  can  be  reasonably  sure  the  system  cannot  be  broken  (using  the  best 
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known  algorithm)  in  a  practical  amount  of  time.  To  be  on  the  conservative  side,  we 
decide  we  want  to  protect  against  a  special  purpose  machine  that  can  perform  10^^ 
operations  per  second.  Specifically,  we  want  to  know  how  large  p  should  be  so  that 
such  a  machine  would  take  at  least  one  year  to  break  the  system. 

In  one  year,  the  hypothetical  machine  can  perform  3  x  10^^  operations.  To  find  the 
size  of  the  desired  p,  solve  the  following  equation  for  b. 


We  get  b  «  606.  This  is  the  number  of  bits  in  the  desired  p.  So,  the  magnitude  of  the 
desired  p  is  about  2^°^  which  is  roughly  266  x  10^^°. 

Hence,  to  be  reasonably  sure  of  attaining  the  desired  level  of  security,  we  find  a  prime 
number  greater  than  266  x  10^*°  which  satisfies  all  the  other  criteria  listed  in  this 
section.  Our  confidence,  however,  is  strictly  based  on  the  assumption  that  breaking 
ElGamal  is  as  difficult  as  finding  discrete  logs  and  the  assumption  that  the  best  known 
algorithm  for  finding  discrete  logs  is  near  optimal. 

3.  p  should  occasionally  be  changed.  This  requirement  is  discussed  in  [ODLY84]  and  is 
related  to  the  discovery  of  new  algorithms  for  computing  discrete  logarithms  in  GF(p). 

4.  p  —  1  must  have  at  least  one  large  prime  factor.  This  requirement  is  discussed  in 
[ODLY84]  and  is  imposed  by  the  Silverman-Pohlig-Hellman  algorithm  which  com- 
putes discrete  logarithms  in  GF{p)  using  on  the  order  operations  and  a  comparable 
amount  of  storage,  where  r  is  the  largest  prime  factor  in  p  —  1. 

5.  p  should  not  be  the  square  of  any  prime.  A  subexponential-time  algorithm  for  com- 
puting discrete  logarithms  in  GF{p^)  has  been  found.  See  [ELGA85b]  for  details. 

11.14.1.1.6     Note  on  subjectPublicKey 

The  ASN.l  data  element  subjectPublicKey,  defined  as  BIT  STRING  in  Annex  (G)  of 
Directory  Documents,  Part  8,  should  be  interpreted  in  the  case  of  ElGamal  as  being  of  type: 

SEQUENCE  {INTEGER,  INTEGER} 

where  the  first  integer  is  the  Arithmetic  Modulus  and  the  second  is  the  primitive  element 
for  the  finite  field.  The  sequence  is  represented  by  the  ASN.l  Basic  Encoding  Rules. 

Implementors  should  take  note  that  the  size  of  the  integers  used  for  these  parameters  is 
expected  to  exceed  the  pragmatic  constraints  specified  for  integers  by  the  upper  layers  SIG. 

11.14.1.2    One-Way  Hash  Functions 
11.14.1.2.1    SQUARE-MOD-N  Algorithm 

Recent  research  regarding  the  square-mod-n  one-way  hash  function  described  in  Annex  D 
of  the  Directory  Documents,  Part  8,  has  revealed  that  the  function  is  not  secure.  Its  use, 
therefore,  is  discouraged. 


(10) 
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11.14.1.2.2  MD2  Algorithm 

MD2  is  a  one-way  hash  function  and  is  described  in  [RFC  11 15].  Implementors  should  note 
that  the  use  of  MD2  may  be  subject  to  license  agreements. 

11.14.1.2.3  Study  of  Other  One-Way  Hash  Functions 

The  Directory  SIG  is  studying  the  applicability  of  alternative  one-way  hash  functions.  Cur- 
rently, this  work  includes  review  of  SNEFRU;  the  Working  Implementation  Agreements 
report  the  status  of  the  work. 

11.14.1.2.4  Use  of  One-Way  Hash  Functions  in  Forming  Signatures 
MD2  may  be  used  to  form  digital  signatures  in  conjunction  with  RSA  or  ElGamal. 

11.14.1.3    ASN.l  for  Strong  Authentication  Algorithms 

This  section  defines  object  identifiers  assigned  to  authentication  algorithms.  The  defini- 
tions take  the  form  of  the  ASN.l  module,  "OIWAlgorithmObjectldentifiers". 

OIWAlgorithmObjectldentif iers  {iso(l)  identif ied-organization(3) 

oiw(14)  dssig(7) 

OIWAlgorithmObjectldentif iers (1)} 

DEFINITIONS  : := 
BEGIN 

EXPORTS 

iad2.  md2WithRSA,  elGamal,  md2WithElGamal ; 
IMPORTS 

authent  icat  ionFramework 

FROM  UsefulDef initions  {joint-iso-ccitt  ds(5)  modules (1) 

usef ulDef  initions (0) } 

ALGORITHM  FROM  Authent icat ionFramework 

authent icat ionFramework ; 

—  categories  of  object  identifiers 

algorithm  OBJECT  IDENTIFIER  : :=  {iso(l)  identif ied-organization(3) 

oiw(14)  dssig(7)  algorithm(2)> 

encriptionAlgorithm  OBJECT  IDENTIFIER  : :=  {algorithm  1} 

hashAlgorthm  OBJECT  IDENTIFIER  ::=  {algorithm  2} 

signature Algorithm  OBJECT  IDENTIFIER    ::=  {algorithm  3} 
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—  algorithms 

md2  ALGORITHM 

PARAMETER  NULL 
::=  {hashAlgorithm  I} 

md2WithRsa  ALGORITHM 
PARAMETER  NULL 
::=  {signatureAlgorithm  1> 

elGamal  ALGORITHM 
I  PARAMETER  NULL 

::=  {encrypt ionAlgorithm  1} 

I  Editor's  Note:  Refer  to  the  June  1990  Working  Agreements  for  information  re- 

I  garding  why  PARAMETER  NULL  is  specified  above  for  the  elGamal  encryption 

I  algorithm. 

nid2WithElGamal  ALGORITHM 
PARAMETER  NULL 
::=  {signatureAlgorithm  2} 

END  —  of  Algorithm  Object  Identifer  Definitions 

11.14.1.4    Note  on  the  ENCRYPTED  MACRO 

I  The  value  associated  with  the  ENCRYPTED  MACRO,  as  defined  in  Directory  Docu- 
I    ments,  part  8,  clause  8.4  shall  be  interpreted  in  the  ceise  of  ElGamal  as  being  type: 

,  SEQUENCE{  INTEGER,  INTEGER  } 

j  The  first  integer  in  the  sequence  is  r  (see  eq  (5),  sec.  11.14.1.1.3).  The  second  integer  is  s 
I   (see  eq  (9),  sec.  11.14.1.1.3). 

11.14.2    Protected  Simple  Authentication 

Protecting  the  user's  distinguished  name  and  password  provides  greater  degrees  of  security 
than  where  passwords  are  not  protected. 

The  procedure  for  achieving  this  protection,  referred  to  as  protected  simple  authentica- 
tion, is  outlined  in  the  Directory  Documents,  Part  8,  clause  5.3.  The  approach  by  which 
protected  identifying  information  may  be  generated  is  outlined  in  the  Directory  Documents, 
Part  8,  clause  5.4.  For  the  purpose  of  these  agreements,  fl  and  /2  as  specified  in  the 
Directory  Documents,  Part  8,  clause  5.4  are  identical  MD2  one-way  functions.  The  algo- 
rithms for  implementation  of  the  MD2  one-way  function  are  described  in  [RFC1115]  (see 
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sec.  11.14.1.1.1).  Note  that  the  use  of  MD2  may  be  subject  to  licensing  agreement.  Use  of 
other  algorithms  for  other  one-way  functions  is  by  bilateral  agreement. 

User  A  generates  Protected2  as  specified  in  the  Directory  Documents,  Part  8,  clause  5.4. 
Authenticator2  is  then  conveyed  to  B  in  the  form  of  SimpleCredentials.  Table  11.14  on 
page  11-73  shows  the  relationship  between  SimpleCredential  fields  and  the  elements  of 
protected  simple  authentication  as  shown  in  figure  2  of  the  Directory  Documents,  Part  8. 

11.14.3    Simple  Authentication 

There  are  two  major  classes  of  authentication  supported  by  the  Directory  (i.e.,  simple  and 
strong  authentication).  Simple  authentication  is  based  on  a  password  being  passed  between 
the  two  associated  entities  (e.g.,  between  a  Directory  User  and  a  DUA,  or  between  two 
DSAs).  In  the  case  of  interaction  between  a  Directory  User  and  a  DUA,  the  pcissword  is 
compared  in  some  way  with  the  password  attribute  in  the  user's  entry  in  the  Directory.  In 
the  case  of  interaction  between  two  DSAs,  this  cannot  be  done  since  the  DSA  object  class, 
as  defined  in  the  Directory  Documents  (Part  7,  clause  6.14)  does  not  contain  a  password 
attribute. 

To  facilitate  simple  authentication  between  DSAs,  it  is  recommended  that  a  DSA  have 
local  access  to  a  list  of  one  or  more  known  DSAs,  with  a  copy  of  each  known  DSA's  password. 
Maintenance  of  that  information  is  done  through  the  use  of  bilateral  agreements  between 
DSA  administrators. 


11-25-1 


December  '89 

11.15    APPENDIX  A:  MAINTENANCE  OF  ATTRIBUTE  SYN- 
TAXES 

11.15.1  Introduction 

The  attribute  types  defined  in  the  Directory  Documents,  Part  6,  and  listed  in  table  11.1 
(page  11-38)  have  requirements,  in  DSAs  which  support  them,  for  underlying  algorithms 
that: 

•  check  attribute  values  for  syntactical  correctness  and  compliance  with  pragmatic  con- 
straints; 

•  match  attribute  values  (comparing  for  equality,  for  matching  substrings,  and  for  relci- 
tive  ordering). 

11.15.2  General  Rules 

A  DSA  may  receive  a  legitimately  encoded  attribute  or  AVA  that  is  unsupported  by  the 
DSA.  If  the  DSA  is  not  required  to  act  on  it,  or  to  store  it  within  an  entry,  it  may  handle 
it  by  passing  it  on  without  error.  Such  attributes  may  also  be  used  in  search  filter-item 
definitions:  in  this  case,  no  error  is  reported,  but  the  filter-item  shall  be  deemed  to  be 
undefined  for  all  entries  in  the  DSA.  This  rule  applies  to  occurrences  of  attributes  in  both 
operation  arguments  and  results. 

Conversely,  a  DSA  must  return  a  suitable  error  if  an  operation  requires  it  to  act  on  or 
store  an  attribute  or  AVA  of  type  unsupported  by  the  DSA.  This  constraint  applies  even 
for  AVAs  that  are  contained  in  attributes  that  take  names  as  values,  since  the  DSA  will  be 
unable  correctly  to  match  the  attribute  values  without  this  attribute  information. 

11.15.3  Checking  Algorithms 

The  subsections  below  give  additional  checks  (beyond  those  directly  implied  by  the  Directory 
Documents)  which  shall  be  applied  to  attributes  before  they  are  stored  in  the  DSA. 

11.15.3.1  distinguishedNameSyntax 

Each  component  AVA  must  be  checked,  unregistered  attribute  types  comprising  an  error; 
check  also  that  no  two  AVAs  in  the  same  RDN  have  the  same  attribute  type. 

11.15.3.2  integerSyntax 

Local  implementations  may  apply  local  limitations. 
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11.15.3.3  telephoneNumberSyntax 

The  value  of  policing  further  rules  is  for  further  study  (this  applies  also  to  telexNumber,  tele- 
texTerminalldentifier,  facsimileTelephoneNumber,  GSFacsimileNonBasicParameters,  xl21Address, 
and  iSDN  Ad  dress). 

11.15.3.4  countryName 

The  value  must  be  checked  for  compliance  with  IS03166:  1981  (E/F).  (Note  that  from  time 
to  time  further  codes  may  be  allocated.) 

11.15.3.5  preferredDeliveryMethod 

The  values  of  the  integer  elements  should  not  be  restricted. 

11.15.3.6  presentationAddress 
No  further  checks  should  be  applied. 

11.15.4    Matching  Algorithms 

Matching  algorithms  are  conveniently  defined  in  terms  of  a  two-step  process: 

1.  Take  the  checked  reference  value,  and  the  value  to  be  matched,  and,  if  necessary, 
reduce  them  to  a  canonical  (i.e.,  standard)  form  (normalization)  appropriate  to  each 
attribute  syntajc. 

2.  Carry  out  the  comparison  in  the  specified  way  (e.g.,  equality,  substrings  or  ordering) 
using  the  appropriate  rules  for  the  value  -  character  string,  integer,  boolean,  etc. 

Note  that  the  lexical  ordering  of  character  strings  (when  supported)  may  be  subject  to  local 
rules. 

IMPORTANT  NOTE:  The  combination  of  normahzation  and  comparison  may  be  re- 
placed, in  a  particular  implementation,  by  equivalent  procedures.  Additional  notes  on  nor- 
medization  are  given  below. 

11.15.4.1  UTCTimeSyntax 

If  the  "seconds"  field  is  absent,  it  shall  be  inserted,  and  set  to  "00",  and  the  form 
converted  to  the  "Z"  form.  Note.  The  normalization  strategy  does  not  match  times  where 
the  stored  form  omits  the  seconds  field,  and  the  compared  form  contains  it,  e.g., 

8804261919Z 

880426191926Z 
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(It  might  have  been  expected  that  these  two  forms,  which  coincide  in  time  to  within  a  few 
seconds,  would  be  considered  identical.) 

11.15.4.2  distinguishedNameSyntax 

For  each  attribute  value,  carry  out  normahzation  in  accordance  with  the  normalization 
rules  defined  for  the  type  (if  registered);  values  corresponding  to  unregistered  attribute  types 
are  left  unchanged  at  this  stage. 

11.15.4.3  caselgnoreListSyntax 

To  facilitate  matching,  particularly  for  substrings,  normalization  may  be  considered  in 
terms  of  a  representation  which  replaces  the  separate  ASN.l  elements  by  a  single  string  with 
a  delimiter. 
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11.16    APPENDIX  B:  GLOSSARY 

The  following  abbreviations  may  be  useful;  not  all  are  used  within  these  agreements. 


ACL 

Arrpss  Control  T<ist 

ACSE 

Asfinriation  ("Innt.rnl  SpTvirf^  Fllpmf^Tit. 

ADDMD 

x^Ulllliilo  tl  <X\>i\Ji\.   LJil.  CC  t(JI  jr    iVlCUlClgdildl  v  JL/Ullldltl 

AETitle 

APDU 

A  nnlir;^  t.ion  Protorr>l  Tlafa  Tin  it. 

ASE 

ADDlication  Servicp  Klpmpnt 

ASN.l 

Abstract  Syntax  Notation  -  1 

AVA 

Attribute  Value  Assertion 

BRM 

CA 

Certification  Authority 

CCTTT 

X  lie.  Ill  tCl  lL<XUI011<Xi   XdCgid^li  ClliU.    XClC|^llL>ilC  V^UllOUltCtul  VC  V^OIlillllu  vCC 

CEN 

Oommittpf*  for  F^iirnripan  N^nrmaliy.at.ion 

v^i-/x  1  ixxxx  u  uv.r\^   xv^x    j_j ux     L/^^cl'XX   J.  Y  vyx  xxxcvxxcyuritxvyxx 

CENELEC 

Committpf  for  Fluronean  Normalization  Klectroniaue 

CEPT 

^Committee  of  Kuronean  Posts  and  TeIer>honesl 

I  V^^^X  XXXXXX  V  u  \-rV^    V^X     J-J  U  X        yj\^  UXX     X              V<i3    U>XX  VX      J.  \^XV.r  LrXX\^XX\rft9  I 

COS 

Corporation  for  Open  Systems 

DAP 

Directory  Access  Protocol 

DIB 

Directory  Information  Base 

DIT 

Directory  Information  Xree 

DMD 

Dirpft.orv  IVrfinacpmpnt  Dnm^iin^ 

X^l  1         ifVyX  V     IVX  Cliil  Ctt^V^  1  llViii  11 U    X^  WlllCLlllO 

Tlirprf  Arv  Sv^tpm  A  cpnt 

DSP 

Directory  System  Protocol 

DUA 

Directory  User  Agent 

EWOS 

Fliirnnpati  Worlc^Hnn  for  Onpn  Svst.pm^ 

J_J  UX  v/L/V^  CLXl      T  T  KJi.  no  11 WL/    IWl                ^11          V  O  U  V^lllo 

FTAM 

File  Transfer,  Access  &  Management 

TNTAP 

XI  ^  X  XXX 

TnfprriT^pra ni lit V  T'pi^nnipal  A^^o^'i^itinn  frir  Tnir^rmAtirin  Ppr*i™PQRincr  ismstn 

ISDN 

Integrated  Services  Digital  Network 

ISO/TEC 

Ttitppiifltiona  1  Oro"ani7atinn  for  fitannarniyflt.ion 

Xll  U^l  llCLvl'h.'llOLl          1  gCl-lllCj  dOlV^ll    XWX         uCxllUCtL  Ul£iu>UlUll 

KT 

XV  X 

LL 

TiOWPr  lavpr^  of  O^T  rnonpl  ilavpr^  l-4i 

MAP 

Ayi  a  n  III  a 1 11  Ti  n  o"   A  iit/^mati/^n  Pi*i~*trt/*/^i 
IVldliUiclt.  LUIlllg  tVli  HJHlclLl*Jli  X  HJtOCLJl 

iviessage  nanaiing  oy&ieiiio 

NIST 

National  Institute  of  Standards  and  TechnoloETV 

^  1  U/UXWXXIXX     XXXOUXUUW'     VX          V  CtiX  X  VX  U>X  VI 1^    U<XX  \X      X.  V>\^XX  XXV/XV^t»T 

NSAP 

Network  Services  Access  Point 

OSI 

Open  Systems  Interconnection 

PKCS 

Public  Key  Crypto  System 

POSI 

Promotion  for  Open  System  Interconnection 

PRDMD 

Private  Directory  Management  Domain 

PSAP 

Presentation  Service  Access  Point 

RDN 

Relative  Distinguished  Name 

ROSE 

Remote  Operations  Service  Element 

SSAP 

Session  Service  Access  Point 

SIG 

Special  Interest  Group 

SPAG 

Standards  Promotion  &;  Application  Group 

TOP 

Technical  and  Office  Protocols 

TSAP 

Transport  Service  Access  Point 
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UL  Upper  layers  of  OSI  model  (layers  5-7) 

UPU  Universal  Postal  Union 
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11.17    APPENDIX  C:  REQUIREMENTS  FOR  DISTRIBUTED 
OPERATIONS 

The  following  material  is  included  for  tutorial  purposes,  and  does  not  represent  material 
additional  to  the  Directory  Documents.  It  is  also  not  intended  as  a  complete  statement 
of  requirements  (the  Distributed  Operations  part  of  the  Directory  Documents  should  be 
referred  to  for  a  complete  treatment). 

11.17.1  General  Requirements 

DSAs  supporting  distributed  operations  and  claiming  support  of  chaining  must  fully  support 
DSP,  as  defined  by  the  Directory  Documents.  DSAs  supporting  distributed  operations  must 
always  be  able  to  accept  incoming  DSP  associations  and  invocations.  DSAs  claiming  support 
of  chaining  must  support: 

•  Loop  detection 

•  Loop  avoidance 

In  passing  on  operations  (when  chaining  or  multi-casting),  the  original  DAP-supplied 
invocation  must  be  passed  on  without  change  of  content.  In  particular,  there  must  be  no 
alteration  in  any  way  of  any  primitive  content. 

The  support  of  a  facihty  for  returning  cross-references  (Directory  Documents,  Part  4, 
clause  10.4.1)  is  optional. 

To  ensure  that  tracelnformation  can  be  analyzed  properly,  DSAs  shall  only  possess  names 
that  are  compliant  with  the  recommendations  of  the  Directory  Documents,  Part  7  (including 
Annex  B). 

11.17.2  Protocol  Support 

11.17.2.1    Usage  of  ChainingArguments 

When  using  ChainingArguments:  ^ 

•  on^ma^or  need  not  be  used  if  requestor  in  CommonArguments  is  used; 

•  targetObjeci  shall  not  be  used  unless  the  target  object  diff"ers  from  object/base  object 
(if  it  is  present,  object/base  object  are  ignored  for  purposes  of  name  resolution); 

•  operationProgress,  tracelnformation,  aliasDereferenced,  aliasedRDNs,  referenceType, 
and  timeLimit  shall  be  generated,  accepted,  and  used  in  accordance  with  the  Directory 
Documents; 

•  returnCross References  and  info  may  optionally  be  generated,  and  shall  always  be  ac- 
cepted. 

^In  this  section,  the  names  of  protocol  elements  (within  ChainingArgimients)  are  italicized. 
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11.17.2,2    Usage  of  ChainingResults 

When  using  ChainingResults:  ^ 

•  cross  References  and  info  may  optionally  be  generated,  and  shall  always  be  accepted. 


3 In  this  section,  the  names  of  protocol  elements  (within  ChainingResults)  are  italicized. 
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11.18    APPENDIX  D:  GUIDELINES  FOR  APPLICATIONS  US- 
ING THE  DIRECTORY 

11.18.1  Tutorial 

11.18.1.1  Overview 

Applications  may  have  a  requirement  for  Directory  functionality.  This  tutorial  provides 
assistance  to  those  groups  intending  to  specify  Directory  usage  for  a  specific  apphcation 
(e.g.,  Message  Handling  Systems). 

11.18.1.2  Use  of  the  Directory  Schema 

11.18.1.2.1  Use  of  Existing  Object  Classes 

Applications  wishing  to  use  the  Directory  should  have  determined  within  a  standard,  Im- 
plementor's  Agreements,  or  on  a  propriety  basis,  the  relevant  Directory  schema  for  their 
objects.  Consider  the  following  two  examples: 

1.  Network  management  applications  may  with  to  define  a  SMAE  object  class. 

2.  File  transfer  applications  may  with  to  define  a  File  Store  object  class. 

Groups  should  examine  relevant  standards  to  determine  if  application-specific  object 
classes  or  attributes  have  been  already  defined  before  considering  any  additional  definition. 
These  object  classes  and  attributes  may  be  found  in  a  variety  of  places  including  a  spe- 
cific application  standard  (e.g.,  [Recommendation  CCITT  '88  X.402  |  ISO  10021-2]  and 
the  Directory  Documents.).  Standardized  object  classes  and  attributes  should  be  strongly 
considered  before  additional  schema  elements  are  created. 

11.18.1.2.2  Kinds  of  Object  Classes 

There  are  effectively  two  kinds  of  object  classes  permitted  within  the  Directory  Doc- 
uments: structural  and  auxiliary.  The  terms  structural  and  auxiliary  are  used  here  for 
convenience  when  referring  to  particular  kinds  of  object  classes.  The  terms  themselves  are 
not  defined  in  the  Directory  Documents. 

Structural  object  classes  have  associated  DIT  structure  rules  (which  control  naming). 
Entries  of  this  object  class  type  are  intended  to  be  instantiated  in  Directory  entries.  A 
structural  object  class  provides  information  on  the  base  mandatory  and  optional  content  of 
a  DIT  entry. 

An  auxiliary  object  class  provides  information  to  enhance  the  mandatory  and  optional 
contents  of  entries.  It  is  always  used  in  conjunction  with  a  structural  object  class. 

The  object  class  hierarchy  is  formed  as  a  result  of  the  definition  of  structural  object 
classes,  and  the  addition  of  auxiliary  object  classes. 
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For  example,  all  object  classes  in  the  Directory  Documents,  Part  7,  are  structural  except 
for  strongAuthentication  User  and  certificationAuthority.  These  two  object  classes  should 
be  considered  auxiliary  and  used  in  conjunction  with  other,  structural  object  classes. 

11.18.1.2.3    Use  of  Unregistered  Object  Classes 

The  Directory  Documents,  Part  2,  clause  9.4.1  provides  a  "special"  form  of  object  class 
called  "unregistered."  An  unregistered  object  class  is  not  assigned  an  object  identifier. 
One  of  the  uses  for  unregistered  object  classes  is  to  provide  a  means  of  creating  a  single 
Directory  entry  which  logically  represents  a  variety  of  object  classes.  Uses  for  unregistered 
object  classes  include: 

•  Locally  adding  attributes  to  a  predefined  superclass; 

•  Locally  making  optional  attribute  types  in  a  predefined  superclass  mandatory; 

•  Creating  an  object  class  derived  from  multiple  superclasses,  without  needless  prolifer- 
ation of  registered  object  classes. 

For  example,  it  may  be  advantageous  to  provide  an  entry  which  represents  a  person  who 
is  both  a  MHS  and  a  FTAM  user. 

Unregistered  object  classes  may  best  be  illustrated  by  example.  Consider  an  entry  which 
represents  a  collection  of  company  entries  for  Fizzy  Company  whose  users  have  MHS  O/R 
addresses.  Using  the  guidelines  above,  the  Fizzy  Company  defines  an  unregistered  object 
class  using  the  structural  object  class  organizationalPerson  from  the  Directory  Documents, 
Part  7,  and  the  auxiliary  object  class  mhs-user  from  the  MHS  standards  [Recommendation 
X.402  I  ISO  10021-2]  as  follows: 

lizzyCompanyPerson  ::=  OBJECT-CLASS 
SUBCLASS  OF  orgeinizationalPerson,  mhs-user 
MUST  CONTAIN  {} 
HAY  CONTAIN  {} 


Note  that  no  object  identifier  is  assigned. 

Also  note  that  since  there  are  not  MUST  or  MAY  CONTAIN's  in  the  fizzyCompanyPer- 
son  Object  Class,  the  last  two  lines  of  the  object  class  assignment  (i.e.,  "MUST  CONTAIN 
MAY  CONTAIN  ")  are  optional.  As  with  the  registered  form  of  object  classes,  an  unreg- 
istered object  class  always  inherits  all  the  attributes  in  any  of  its  superclasses.  There  is 
no  mechanism  defined  whereby  a  subclass  may  selectively  inherit  attributes  from  its  super- 
classes. 

An  unregistered  object  class  always  appears  as  a  leaf  in  the  Object  Class  tree,  (i.e..  An 
unregistered  object  class  may  not  be  a  superclass  of  some  other  object  class). 

Using  unregistered  object  classes  in  conjunction  with  multiple  inheritance  is  useful  as 
shown  by  figure  11.6  in  which  three  ways  of  creating  the  same  two  object  classes  are  shown. 
Either  three,  four,  or  five  registered  object  classes  are  used. 

Examples  (a)  and  (c)  in  figure  11.6  are  both  better  ways  of  defining  the  object  classes 
than  that  in  example  (b),  even  though  example  (c)  needs  to  use  one  more  registered  object 
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per  mhs  ae 

\  /      \  / 

mhs-per [ur]  mhs-ae[ur] 


I         per  ae        I  per  i 

I  I  I  I      \  / 

I      mhs-per    mhs-ae      I  mhs-per 


mhs 


\ 


/ 

mhs-ae 


ae 


Example  a 


Excimple  b 


Excimple  c 


[ur]        =  unregistered 
per         =  person 
mhs         =  mhs-user 
ae  =  applicationEntity 


Figure  11.6.  Three  Ways  of  Creating  Two  Object  Classes. 


class  than  example  (b).  This  is  because  the  multiple  inheritance  technique,  used  in  examples 
(a)  and  (c),  enables  a  Directory  User  searching  the  Directory  to  easily  create  a  filter  to  find 
all  entries  that  contain  mhs-user  attributes,  based  on  a  value  in  the  object  class  attribute 
(Each  Directory  entry  contains  a  list  of  the  object  identifiers  of  the  object  classes  it  has 
inherited  from,  so  the  filter  would  just  have  to  find  all  entries  that  held  the  object  identifier 
value  of  mhs-user). 

Example  (a),  which  uses  three  registered  object  classes,  is  better  than  example  (c),  which 
uses  five,  because  registering  the  extra  two  object  classes  does  not  provide  any  advantage 
over  not  registering  them,  and  the  first  method  avoids  needless  proliferation  of  registered 
object  classes. 

11.18.1.2.4    Side  Effects  of  Creating  Unregistered  Object  Classes 

This  section  discusses  two  side  effects  of  creating  unregistered  object  classes. 

1.  When  an  unregistered  object  class  is  defined  from  a  single  superclass,  there  is  no 
means  available  to  distinguish  between  the  two.  Within  the  local  scope  for  which 
the  unregistered  class  is  defined,  all  relevant  entries  are  considered  to  belong  to  the 
unregistered  class. 

The  following  is  an  example  of  this  problem: 

An  object  class  of  oCl(reg)  has  attribute  type  atl  mandatory  and  at2  op- 
tional. An  unregistered  form  of  this,  oCl(unreg)  is  created,  which  makes  at2 
mandatory.  When  an  Add  Entry  operation  is  received  with  both  attributes 
present,  the  entry  could  belong  to  either  form  of  oCl;  it  is  indeterminate. 
After  the  entry  is  added  a  Modify  Entry  operation  is  received  which  requests 
the  removal  of  attribute  type  at2.  It  is  not  clear  if  this  operation  should 
succeed,  or  whether  an  object  class  violation  should  be  reported.  If  the 
attribute  may  be  removed,  then  the  entry  belonged  to  the  oCl(reg)  object 
class  and  the  unregistered  form  never  existed,  otherwise  if  the  attribute  may 
not  be  removed,  then  the  entry  belonged  to  oCl(unreg)  and  the  registered 
form  no  longer  exists. 

2.  More  than  one  unregistered  object  class  cannot  be  defined  from  the  same  superclcLss(es) 
for  use  within  the  same  local  scope,  as  there  is  no  means  available  to  distinguish  the 
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classes  from  one  another. 

11.18.2  Creation  of  New  Object  Classes 

If  no  appropriate  object  class  is  available,  a  new  object  class  may  be  defined.  This  should 
only  be  done  if  no  standardized  object  classes  and  attributes  can  fulfill  the  requirements. 

11.18.2.1  Creation  of  New  Subclasses 

Generally,  an  application-specific  object  class  is  defined  as  a  subclass  of  a  pre-existing  Di- 
rectory object  class.  These  object  classes  are  specified  in  the  Directory  Documents,  Part  7. 
The  subclass  may  be  structural  or  auxiliary.  Optional  attributes  of  the  superclass  may  be 
made  mandatory.  New  attributes  may  also  be  added. 

For  example,  MHS  has  used  the  Directory  structural  object  class  applicationEntity  to 
derive  the  object  class  for  their  MHS-specific  application  entity  MTAs. 

If  absolutely  no  relevant  object  class  is  available,  an  object  class  may  be  defined  as  a 
subclass  of  the  basic  object  class  called  "Top" . 

If  no  appropriate  object  class  is  available,  a  new  object  class  may  be  defined.  This 
should  only  be  undertaken  if  no  standardized  object  class  can  fulfill  the  requirements.  When 
defining  new  object  classes  the  object-class  macro,  as  defined  in  the  Directory  Documents, 
Part  2,  clause  9.4.6,  should  be  used. 

If  new  subclasses  are  defined,  suggested  or  required  name  forms  may  also  be  specified  in 
text . 

11.18.2.2  Creation  of  New  Attributes 

If  no  appropriate  attributes  are  available,  a  new  attribute  type  may  be  defined.  This 
should  only  be  undertaken  if  no  standardized  attributes  can  fulfill  the  requirements.  When 
defining  new  attributes  the  attribute  macro,  as  defined  in  the  Directory  Documents,  Part 
2,  clause  9.5.3,  should  be  used. 

11.18.3  DIT  Structure  Rules 

Applications  may  desire  to  provide  guidance  on  DIT  structure  rules  and  naming.  As  with 
object  classes,  standardized  or  suggested  structure  (including  naming)  rules  from  the  Di- 
rectory Documents  part  7,  Annex  B  and  application-specific  standards  should  be  consulted 
before  providing  new  structure  rules.  Annex  B  in  the  Directory  Documents,  Part  7,  provides 
guidelines  on  how  to  specify  this  information.  Structure  rules  associated  with  superclasses 
should  be  adopted  wherever  suitable. 
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11.19    APPENDIX  E:  TEMPLATE  FOR  AN  APPLICATION  SPE- 
CIFIC PROFILE  FOR  USE  OF  THE  DIRECTORY 

The  template  defined  below  should  be  used  by  OIW  SIGs  intending  to  specify  Directory 
usage.  Such  application  specific  profiles  shall  be  contained  in  application  specific  chapters 
of  the  OIW  agreements.  The  information  under  each  heading  should  be  filled  in  (the  text 
under  each  heading  provides  guidance  on  the  intent  of  the  section  and  should  not  be  included 
in  the  profile). 

•  PROFILE  TITLE 

Application  specific  profiles  are  named  in  the  following  way: 

OIW  <SIG-NAHE>  <DESCRIPTOR>  DIRECTORY  PROFILE 
(e.g.,  OIW  DIRECTORY  STRONG  AUTHENTICATION  DIRECTORY  PROFILE  ) 

•  OTHER  PROFILES  SUPPORTED 

Other  OIW  Directory  profiles  which  are  to  be  used  by  this  specific  application  are  listed 
here.  Attributes,  attribute  sets,  object  classes  and  structure  rules  that  are  referenced 
in  these  profiles  need  not  be  enumerated  below. 

•  STANDARD  APPLICATION  SPECIFIC  ATTRIBUTES  AND  ATTRIBUTE  SETS 

Any  attributes  supported  from  the  relevant  standards.  For  example,  the  MHS  SIG 
might  include  mhs-or-address  here. 

•  STANDARD  APPLICATION  SPECIFIC  OBJECT  CLASSES 

Any  object  classes  supported  from  the  relevant  standards.  For  example,  the  MHS  SIG 
might  include  mhs-user  here. 

•  OIW  APPLICATION  SPECIFIC  ATTRIBUTES  AND  ATTRIBUTE  SETS 

This,  optional,  component  of  this  profile  allows  for  the  specification  of  OIW  application 
specific  attributes  and  attribute  sets.  This  section  of  this  template  should  be  used 
rarely  and  with  consideration  that  no  standard  profile  or  attribute/attribute  set  exists 
which  can  be  used. 

•  OIW  APPLICATION  SPECIFIC  OBJECT  CLASSES 

This,  optional,  component  of  this  profile  allows  for  the  specification  of  OIW  application 
specific  object  classes.  This  section  of  this  template  should  be  used  rarely  and  with 
consideration  that  no  standard  profile  or  object  class  exists  which  can  be  used. 

•  STRUCTURE  RULES 

Guidance  for  t)IT  structural  rules,  provided  only  when  structure  rules  associated  with 
superclasses  are  not  adopted.  The  Directory  Documents,  Part  7,  Annex  B  provide  an 
example  and  guideline  to  use  in  specifying  this  information. 
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Table  11.1.  Pragmatic  Constraints  for  Selected  Attributes  (Part  1  of  2) 


Attribute  Type 

Content 

Constraints 

Primary 
Source 

Notes 

Aliased  Object  Name 

Distinguished 
Name 

Note  3  (page  11-39) 


Business  Category 

T.61   or  Printable 
String 

ub-business-category 
128 

CCITT 
A. 520 

Common  Name 

T.61   or  Printable 
String 

ub-common-name 
64 

CCITT 

V    CO  A 

A. 520 

Country  Name 

Printable  String 

2 

ISO 
3166 

Description 

T.61    or  Printable 
String 

ub-description 
1024 

CCITT 
X.520 

About  1  screen  full 

Facsimile  Telephone 
Number 

Facsimile  Telephone 
Number 

ub-telephone-number 
32 

CCITT 
X.520 

Optionally  includes  G3 
non-basic  parameters 

1  1  1  T~\T^^ r  r\j*\i  1  n ^  c  ttc  1 

International  ISDN 

L\  UIIIUCI 

Numeric  String 

ub-isdn-address 
1  fi 

1  u 

CCITT 
X  590 

E.164  Intemat'l  ISDN 
Number 

Knowledge  Informa- 
tion 

T.61    or  Printable 
String 

1024 

NIST 

About  1  screen  full 

Locality  Name 

T.61    or  Printable 
String 

ub-locality-name 
1 98 

CCITT 

Member 

Distinguished 

IN  dlllc 

Note  3  (page  11  -  39) 

Object  Class 

Object  Identifier 

256  octets 

NIST 

Organization  Name 

T.61   or  Printable 
String 

ub-org  an  iz  at  ion-name 
64 

coil  i 
x.520 

Organizational  Unit 
Name 

T.61   or  Printable 
String 

ub-organizational-unit- 
name  64 

CCITT 
X.520 

Owner 

Distinguished 
Name 

Note  3  (page  11  -  39) 

Physical  Delivery 
Office  Name 

T.61    or  Printable 
String 

ub-physical-office-name 
128 

CCITT 
X.520 

Post  Office  Box 

T.61    or  Printable 
String 

ub-post-ofRce-box 
40 

CCITT 
X.520 

Postal  Address 

Postal  Address 

ub-postal-line  6 
ub-postal-string  30 

CCITT 
X.520 

UPU 

Presentation  Address 

Presentation 
Address 

224  octets 

NIST 

Note  2  (page  11  -  39), 
ISO  7498.3  &  X.200 

Role  Occupant 

Distinguished 
Name 

Note  3  (page  11  -  39) 

See  Also 

Distinguished 
Name 

Note  3  (page  11-39) 
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Table  11.1.  Pragmatic  Constraints  for  Selected  Attributes  (Part  2  of  2) 


Attribute  Type 

Content 

Constraints 

Primary 
Source 

Notes 

Serial  Number 

Printable  String 

ub-serial-number 
64 

CCITT 
X.520 

State    or  Province 
Name 

T.61   or  Printable 
String 

ub-state-name 
128 

CCITT 
X.520 

Street  Address 

T.61   or  Printable 
String 

ub-street- address 
128 

CCITT 
X.520 

Surname 

T.61   or  Printable 
String 

ub-surname 
64 

CCITT 
X.520 

Telephone  Number 

Printable  String 

ub- telephone-number 
32 

CCITT 
X.520 

E.123 

Teletex  Terminal 
Identifier 

Teletex  Terminal 
Identifier 

ub-teletex-terminal-id 
1024 

CCITT 
X.520 

Optionally  includes 
Teletex  non-basic  pa- 
rameters (upper  bound 
ffs) 

Telex  Number 

Telex  Number 

ub-telex-number  14 
ub-country-code  4 
ub-answerback  8 

CCITT 
X.520 

Contains  sequence  of 
telex  number,  country 
code,  and  answerback 

Title 

T.61   or  Printable 
String 

ub-title 
64 

CCITT 
X.520 

User  Password 

Octet  String 

u  b- user- p  ass  wor  d 
128 

CCITT 
X.520 

AUow  long  passwords 
generated  by  machine 

X.121  Address 

Numeric  String 

ub-xl21-address 
15 

CCITT 
X.520 

X.121 

Notes  for  table  11.1 

1.  The  pragmatic  constraints  of  these  parameters  are  defined  in  other  standards.  We 
will  accommodate  these  values  in  our  pragmatic  constraints. 

2.  Presentation  address  is  composed  of  "X"  NSAP  addresses,  and  three  selectors, 
(20X  -f-  32  -f-  16  +  16),  e.g.,  i{  X  =  1,  this  would  be  84.  These  numbers  are  based 
on  the  most  recent  implementors'  agreements.  With  8  NSAP  addresses  this  value  is 
224. 

3.  Pragmatic  constraints  are  only  applied  to  the  individual  components  of  Distinguished- 
Name  as  defined  in  the  Directory  Documents,  Part  2.  Not  all  components  of  a  DN  will 
necessarily  be  understood  by  an  implementation. 

4.  Implementors  should  be  aware  that  constraints  on  Postal  Address  may  not  be  suffi- 
cient for  some  markets. 
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Table  11.2.  Directory  Access  Service  Support. 


Support 
Classification 

Operations  and  Errors 

DUA 

DSA 

Comments 

-  BIND  and  UNBIND  - 

DirectoryBind 
Directory  Unbind 

r 
r 

r 
r 

-  OPERATIONS  - 

-  READ  OPERATIONS  - 
Read 
Compare 
Abandon 

n 
n 
n 

r 
r 

r  (note  2) 

-  SEARCH  OPERATIONS  - 
List 
Search 

n 
n 

r  (note  1) 
r  (note  1) 

-  MODIFY  OPERATIONS  - 
AddEntry 
Remove  Entry 
ModifyEntry 
ModifyRDN 

n 
n 
n 
n 

r 
r 
r 
r 

-  ERRORS  - 
Abandoned 
AbandonedFailed 
AttributeError 
NameError 
Referral 
SecurityError 
ServiceError 
UpdateError 

(note  4) 
(note  4) 
(note  4) 
(note  4) 
(note  4) 
(note  4) 
(note  4) 
(note  4) 

r 
r 
r 
r 

r  (note  3) 

r 

r 

r 

Notes  for  table  11.2 

1.  As  performance  of  Search  and  List  operations  can  consume  significant  resources,  the 
policies  of  some  centralized  DSAs  may  be  that  such  operations  will  not  be  performed. 
For  these  cases,  the  reply  to  the  requests  for  such  operations  would  be  ServiceError 
with  the  "unwillingToPerform"  Service  Problem. 

2.  Reference  Directory  Documents,  Part3,  clause  9.3.6 

3.  Centralized  DSAs  would  not  generate  referrals. 

4.  See  EntrylnformationSelection  information  under  Common  Data  Types  (table  11.3, 
Part  6) 
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Table  11.3.  DAP  Protocol  Support  (Part  1  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  BIND  and  UNBIND  - 

DirectoryBind 

DirectoryBindArgument 

M 

s 

credentials 

\j 

c 

•3 

simple 

O 

s 

name 

G 

s 

validity 

O 

o 

password 

G 

s 

strong 

O 

o 

See  Strong  Authentication  Protocol  Conformance  Profile  for  re- 

quirements when  strong  authentication  is  supported. 

externalProcedure 

O 

o 

versions 

o 

s 

Supported  value:  vl988 

DirectoryBind  Result 

s 

G 

credentials 

o 

G 

Shall  be  the  same  CHOICE  as  in  DirectoryBindArgument. 

simple 

o 

G 

name 

s 

G 

validity 

o 

O 

password 

o 

O 

strong 

o 

O 

See  Strong  Authentication  Protocol  Conformance  Profile  for  re- 

quirements when  strong  authentication  is  supported. 

externalProcedure 

0 

o 

versions 

s 

o 

Supported  value:  vl988 

DirectoryBindError 

s 

G 

versions 

s 

O 

Supported  value:  vl988 

ServiceProblem 

s 

G 

Supported  value:  unavailable 

SecurityProblem 

s 

G 

Supported  values:  inappropriate  Authentication,  invalidCredentials 

DirectoryUnbind 

The  DirectoryUnbind  has  no  arguments. 
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Table  11.3.  DAP  Protocol  Support  (Part  2  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  OPERATIONS,  ARGUMENTS  AND  RESULTS  - 

-  READ  OPERATIONS  - 

Read 

ReadArgument 

M 

S 

object 

M 

s 

selection 

0 

s 

See  note  2  on  page  11  -  47. 

CommonArguments 

O 

s 

Read  Result 

S 

G 

entry 

S 

M 

^ommonrtesuiis 

c 

c 

Compare 

CompareArgument 

M 

S 

object 

M 

S 

purported 

M 

S 

CommonArguments 

O 

S 

Compare  Result 

S 

G 

DistinguishedName 

s 

G 

matched 

s 

M 

fromEntry 

s 

G 

commonResults 

s 

G 

Abandon 

AbandonArgument 

M 

S 

invokeld 

M 

S 

AbandonResult 

S 

G 

-  SEARCH  OPERATIONS  - 

List 

ListArgument 

M 

S 

object 

M 

S 

CommonArguments 

0 

S 

ListResult 

S 

G 

listlnfo 

S 

G 

DistinguishedName 

s 

G 

subordinates 

s 

M 

Rel. DistinguishedName 

s 

M 

For  the  case  where  subordinates  is  empty  set,  RDN  is  absent. 

aHasEntry 

s 

G 

fromEntry 

s 

G 

partialOutcomeQualifier 

s 

G 

Common  Results 

s 

G 

UncorrelatedListlnfo 

s 

G(0) 

ListResult 

s 

G 

See  note  1  on  page  11-47  for  additioneJ  information  related  to 

the  DSA  support  cl2issification. 
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Table  11.3.  DAP  Protocol  Support  (Part  3  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

Search 

SearchArgument 

M 

S 

baseObject 

M 

s 

subset 

O 

s 

niter 

O 

s 

searchAliases 

O 

s 

selection 

O 

s 

CommonArguments 

O 

s 

SearchResult 

s 

G 

searchinfo 

s 

G 

DistinguishedName 

s 

G 

entries 

s 

M 

partialOutcomeQualifier 

s 

G 

CommonResults 

s 

G 

uncorrelatedSearchinfo 

s 

G  (0) 

SearchResult 

s 

G 

partialOutcomeQuahfier 

s 

G 

limitProblem 

s 

G 

unexplored 

s 

G 

unavailableCriticalExt 

s 

O 

-  MODIFY  OPERATIONS  - 

A  rlrlFnf  rv 

AddEntry  Argument 

M 

s 

object 

M 

s 

entry 

M 

s 

CommonArgument 

O 

s 

AddEntry  Result 

s 

G 

Remove  Entry 

RemoveEntry  Argument 

M 

s 

object 

M 

s 

CommonArguments 

O 

s 

RemoveEntry  Result 

s 

G 

ModifyEntry 

Modify  EntryArgument 

M 

s 

object 

M 

s 

changes 

M 

s 

At  least  one  entry  modification  must  be  supported. 

addAttribute 

0 

s 

removeAttribute 

0 

s 

addValues 

0 

s 

removeValues 

O 

s 

CommonArguments 

0 

s 

ModifyEntryResult 

s 

G 
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Table  11.3.  DAP  Protocol  Support  (Part  4  of  7) 


JT  iUu^JCOl  XJlclllCIlt 

Support 
Classification 

v^UllilllCllUo 

r»TT  A 
UU  A 

JJoA 

IVl  O  U 1 1  y  rv  J-/ i  N 

A/f  rir^ifvR  T^IV  A  roriimf^Tit' 

M 

S 

object 

M 

S 

newRDN 

M 

O 

s 

O 

G 

Modify  RDN  Result 

c 

b 

G 

-  ERRORS  AND  PARAMFTFRS  - 

Abandoned 

AbandonFailed 

problem 

S 

M 

operation 

S 

M 

AttributeError 

object 

S 

M 

problems 

S 

M 

Min.     1  error  (See  Directory  Documents,  Part  3, 

clause  12.4.2.2) 

type 

S 

M 

value 

S 

G 

NameError 

problem 

S 

M 

matched 

S 

M 

Referral 

candidate 

s 

G 
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Table  11.3.  DAP  Protocol  Support  (Part  5  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

SecurityError 

problem 

s 

M 

ServiceError 

problem 

s 

M 

UpdateError 

problem 

s 

M 

-  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

ServiceControls 

o 

s 

Security  Parameters 

o 

s 

See  Section  11.8.8. 

certification-path 

o 

s 

name 

0 

s 

time 

0 

s 

random 

o 

s 

target 

0 

s 

requestor 

o 

s 

OperationProgress 

0 

S(0) 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

O 

s 

aliasedRDNs 

0 

S(0) 

extensions 

0 

s 

identifier 

M 

s 

critical 

O 

s 

item 

M 

s 

CommonResults 

SecurityParameters 

O 

G(0) 

See  Section  11.8.8. 

certification-path 

0 

G 

name 

0 

G 

time 

0 

G 

random 

O 

G 

target 

0 

G 

performer 

0 

G(0) 

aliasDereferenced 

0 

G 
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Table  11.3.  DAP  Protocol  Support  (Part  6  of  7) 


rrotocol  Llement 

Support 
Classification 

Comments 

DUA 

1  DSA 

-  COMMON  DATA  TYPES  - 

ServiceControIs 

options 

o 

s 

priority 

O 

s 

time  Limit 

O 

s 

sizeLimit 

0 

s 

scopeUiKeierrai 

O 

s 

EntrylnformationSelection 

attributeTypes 

o 

S 

allAttributes 

o 

s 

Must  support  at  least  one  of  the  CHOICE. 

select 

o 

s 

■     r  rp 

mio  1  ypes 

o 

s 

Entrylnformation 

DistinguishedName 

S 

M 

fromEntry 

S 

G 

SET  OF  CHOICE 

S 

G 

AttributeType 

S 

G 

Attribute 

S 

G 

Filter 

Must  support  at  least  one  of  the  CHOICE. 

item 

0 

S 

and 

0 

s 

or 

0 

s 

not 

o 

s 

Filterltem 

equality 

0 

s 

substrings 

o 

s 

type 

M 

s 

strings 

M 

s 

initial 

o 

s 

Must  support  at  least  one  of  the  CHOICE. 

any 

o 

s 

final 

o 

s 

greaterOr  Equal 

o 

s 

lessOrEqual 

o 

s 

present 

0 

s 

approximateMatch 

0 

s 
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Table  11.3.  DAP  Protocol  Support  (Part  7  of  7) 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

Security  Parameters 

O 

O 

See  Section  11.8.8. 

certification-path 

O 

S 

name 

0 

S 

time 

O 

S 

random 

o 

b 

target 

o 

S 

ContinuationReference 

targetObject 

o 

M 

aliasedRDNs 

0 

G 

OperationProgress 

o 

M 

nameResolutionPhase 

o 

M 

nextRDNToBeResolved 

0 

G 

rdnsResolved 

o 

G 

AccessPoint 

0 

M 

AccessPoint 

Name 

o 

M 

Pr  eser  tation  Address 

0 

M 

pSelector 

o 

G 

sSelector 

0 

G 

tSelector 

o 

G 

nAddress 

o 

M 

Notes  for  table  11.3 

1 .  As  performance  of  Search  and  List  operations  can  consume  significant  resources,  the 
policies  of  some  centralized  DSAs  may  be  that  such  operations  will  not  be  performed. 
For  these  cases,  the  reply  to  the  requests  for  such  operations  would  be  ServiceError 
with  the  "unwillingToPerform"  Service  Problem. 

2.  See  EntrylnformationSelection  information  under  Common  Data  Types  (table  11.3, 
part  6) 
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Table  11.4.  Directory  System  Service  Support. 


Operations  and  Errors 

Support 
Classification 

Comments 

Request 

Response 

-  RTND  and  IINRIND  - 

DSABind 

n  (notes  1,2) 

r 

DSAUnbind 

n  (notes  1,2) 

r 

-  OPERATIONS  - 

-  CHAINED  READ  OPERATIONS  - 

ChainedRead 

n  (notes  1,2) 

r 

ChainedCompare 

n  (notes  1,2) 

r 

chained  A  ban  don 

n  (note  1) 

r 

-  CHAINED  SEARCH  OPERATIONS  - 

ChainedList 

n  (note  1) 

r 

ChainedSearch 

n  (note  1) 

r 

-  CHAINED  MODIFY  OPERATIONS  - 

ChainedAddEntry 

n  (note  1) 

r 

ChainedRernoveEntry 

n  (note  1) 

r 

ChainedEntry 

n  (note  1) 

r 

ChainedModifyRDN 

n  (note  1) 

r 

-  ERRORS  - 

Abandoned 

n  (note  1) 

r 

Abandonfailed 

n  (note  1) 

r 

AttributeError 

n  (note  1) 

r 

NameError 

n  (note  1) 

r 

DSAReflferal 

n  (note  1) 

r 

SecurityError 

n  (note  1) 

r 

SeviceError 

n  (note  1) 

r 

UpdateError 

n  (note  1) 

r 

Notes  for  table  11.4 

1.  Necessary  when  supporting  the  chained  mode  of  interaction. 

2.  Some  of  these  operations  may  be  necessary  to  support  distributed  authentication. 
This  requirement  is  distinct  from  support  for  chained  mode  of  interaction. 
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Table  11.5.  DSP  Protocol  Support  (Part  1  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  BIND  and  UNBIND  - 

DSABind 

DirectoryBindArgument 

M 

S 

credentials 

G 

S 

simple 

G 

S 

name 

G 

S 

validity 

0 

o 

password 

G 

s 

strong 

O 

o 

See  Strong  Authentication  Protocol  Conformance  Profile 

for  requirements  when  strong  authentication  is  supported. 

externalProcedure 

0 

0 

versions 

G 

s 

Supported  value;  vl988 

DSABindResult 

S 

G 

credentials 

S 

G 

Shall  be  the  same  CHOICE  as  in  DirectoryBindArgument. 

simple 

S 

G 

name 

S 

G 

validity 

0 

O 

password 

S 

G 

strong 

o 

O 

See  Strong  Authentication  Protocol  Conformance  Profile 

for  requirements  when  strong  authentication  is  supported. 

externalProcedure 

o 

O 

versions 

S 

G 

Supported  value:  vl988 

DirectoryBindError 

S 

G 

versions 

S 

G 

Supported  value:  vl988 

ServiceProblem 

S 

G 

Supported  values:  busy  and  unavailable. 

SecurityProblem 

s 

G 

Supported  values:  inappropriateAuthentication,  invalid- 

Credentials. 

DSAUnbind 

The  DSAUnbind  has  no  argvunents. 
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Table  11.5.  DSP  Protocol  Support  (Part  2  of  9) 


Support 
Classification 

(lommpn  t  q 

All  1^11  LO 

Request 

Response 

-  OPERATIC 

)NS,  ARC 

JMENTS  A 

ND  RESULTS  - 

-  CHAINED  READ  OPERATIONS  - 

1 1  cL  1 1 1 C  U,  JXC  a.  U, 

v_^ii<iiuiiig/\.rguin.enii 

M 

S 

IVCclU/\rgUlllCll  L 

M 

S 

object 

M 

selection 

Kj 

c 

c 

\j 

o 
o 

(!      in  in  trRpQiilf 

1  i  CL 1 1 1 1 1 1     X      O  U.  1 L 

c 

M 

JXC  clU  XVC  o  U 1 1 

s 

M 

^^n  t  T  V 

s 

M 

CommonResults 

s 

G 

ChainedCompare 

v^iidllilllt/^l  t  Uilicii  L 

M 

S 

C  omp  are  A  rgu  men  t 

M 

S 

object 

M 

S 

purported 

M 

s 

CommonArguments 

G 

s 

ChainingResult 

S 

M 

CompareResult 

s 

M 

DistinguishedName 

s 

G 

matched 

s 

M 

fromEntry 

s 

G 

CommonResults 

s 

G 

Chained  Abandon 

AbandonArgument 

M 

S 

invokeld 

M 

S 

AbandonResult 

s 

G 

{ 
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Table  11.5.  DSP  Protocol  Support  (Part  3  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  OPERATIONS,  ARGUMENTS  AND  RESULTS  - 

-  CHAINED  SEARCH  OPERATIONS  - 

ChainedList 

ChainingArguments 

M 

S 

ListArgument 

M 

S 

object 

M 

S 

CommonArguments 

G 

S 

ChainingResults 

S 

M 

ListResult 

S 

M 

listlnfo 

S 

G 

DistinguishedName 

S 

G 

subordinates 

S 

M 

Rel. DistinguishedName 

S 

M 

aliasEntry 

s 

G 

fromEntry 

s 

G 

partialOutcomeQualifier 

s 

G 

CommonResults 

s 

G 

uncorrelatedListlnfo 

s 

G 

ListResult 

s 

G 

ChainedSearch 

SearchArgument 

M 

S 

baseObject 

M 

s 

sugset 

G 

s 

filter 

G 

s 

searchAliases 

G 

s 

selection 

G 

s 

CommonArguments 

G 

s 

ChainingResults 

S 

M 

SearchResult 

S 

M 

Searchinfo 

s 

M 

DistinguishedName 

s 

G 

entries 

s 

M 

partialOutcomeQualifier 

s 

G 

Common  Results 

S 

G 

uncorrelatedSearchinfo 

s 

G 

SearchResult 

s 

G 

partialOutcomeQualifier 

S 

G 

limitProblem 

s 

G 

unexplored 

S 

G 

unavailableCriticalExt 

s 

G 
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Table  11.5.  DSP  Protocol  Support  (Part  4  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  <^nAlINryU  MUUIJ:'  Y  vJrhiRAilUJNb  - 

UnameuAaatintry 

ChainingArguments 

M 

S 

AddEntry  Argument 

M 

S 

object 

M 

S 

entry 

M 

S 

CommonArguments 

G 

S 

UnamingKesults 

S 

M 

AddEntry  Results 

S 

M 

C/hainedKemoveEntry 

C/hammgArguments 

M 

S 

RemoveEntry  Argument 

M 

S 

object 

M 

S 

CommonArguments 

G 

s 

ChainingResults 

S 

M 

RemoveEntry  Result 

s 

M 

ChainedModify  Entry 

ChainingArguments 

M 

s 

Modify  Entry  Argument 

M 

s 

object 

M 

s 

changes 

M 

s 

addAttnbute 

G 

s 

removeAttribute 

G 

s 

add  Values 

G 

s 

removeValues 

G 

s 

CommonArguments 

ri 

c 
o 

ChainingResults 

S 

M 

ModifyEntryResult 

S 

M 

ChainedModifyRDN 

ChainingArguments 

M 

s 

Modify  RDN  Argument 

M 

s 

object 

M 

s 

newRDN 

M 

s 

deleteOldRDN 

G 

s 

CommonArguments 

G 

s 

ChainingResults 

S 

M 

Modify  RDN  Result 

S 

M 
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Table  11.5.  DSP  Protocol  Support  (Part  5  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

R  PQrion  QP 

-  ERRORS  and  PARAMETERS  - 

Abandoned 

AbandonFailed 

problem 

S 

M 

operation 

s 

M 

AttributeError 

Min.    1  error  (see  Directory  Documents,  part3, 

clause  12.4.2.2) 

object 

s 

M 

problems 

s 

M 

problem 

s 

M 

type 

s 

M 

value 

s 

G 

NameError 

problem 

s 

M 

matched 

s 

M 

DSARefFeral 

ContinuationReference 

s 

M 

contextPrefix 

s 

G 

SecurityError 

problem 

s 

M 
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Table  11.5.  DSP  Protocol  Support  (Part  6  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

c 

S 

M 

Up  date  Error 

s 

G 

problem 

s 

M 

-  COMMON  ARGUMENTS  /  RESULTS  - 

Common  Arguments 

ServiceControls 

G 

S 

SecurityParameters 

0 

S 

see  Section  11.8.8. 

requestor 

G 

S 

OperationProgress 

G 

s 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

G 

s 

aliasedRDNs 

G 

s 

extensions 

G 

s 

identifier 

M 

s 

critical 

G 

s 

item 

M 

s 

ConrunonResults 

SecurityParameters 

S 

o 

See  Section  11.8.8. 

requestor 

s 

G 

aliasDereferenced 

s 

G 
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Table  11.5.  DSP  Protocol  Support  (Part  7  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  COMMON  DATA  TYPES  - 

ServiceControls 

options 

G 

S 

priority 

G 

S 

timeLimit 

G 

S 

sizeLimit 

G 

S 

scopeOfReferral 

G 

S 

EntrylnformationSelection 

attributeTypes 

G 

S 

allAttributes 

G 

s 

select 

G 

s 

infoTypes 

G 

s 

Entrylnformation 

DistinguishedName 

S 

M 

fromEntry 

S 

G 

SET  OF  CHOICE 

S 

G 

AttributeType 

s 

G 

Attribute 

s 

G 

Filter 

item 

G 

S 

and 

G 

S 

or 

G 

S 

not 

G 

s 

Filterltem 

equality 

G 

s 

substrings 

G 

s 

type 

G 

s 

strings 

G 

s 

initial 

G 

s 

any 

G 

s 

final 

G 

s 

greaterOrEqual 

G 

s 

lessOrEqual 

G 

s 

present 

G 

s 

approximateMatch 

G 

s 
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Table  11.5.  DSP  Protocol  Support  (Part  8  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

-  COMMOl 

N   JJAiA  i 

DISTRIBUTED  OPERATION  - 

originator 

G 

S 

targetObject 

G 

S 

op  er  at  ion  P  rogress 

G 

s 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

G 

s 

tracelnformation 

M 

s 

aliasDereferenced 

G 

s 

aliasedRDNs 

G 

s 

returnCrossRefs 

G 

s 

See  Directory  Documents,  Part  4,  clause  10.4.1 

referenceType 

G 

s 

Domainlnfo 

o 

0 

timeLimit 

G 

s 

Security  Parameters 

0 

s 

See  note  1  tnaffe  11  —  .^Tl  ree^arninp"  tlip  Qiinnnrt 

sification  for  Request.  Also  see  Section  11.8.8 

ChainingResults 

Info 

O 

o 

crossReferences 

c 

G 

SecurityParameters 

S 

o 

See  note  1  (page  11-57)  regarding  the  support  clas- 

sification for  Response.  Also  see  Section  11.8.8 

Cross  Reference 

contextPrefix 

S 

M 

See  Directory  Documents,  Part  4,  clause  12.4.2.2 

accessPoint 

S 

M 

Tracelnformation 

Traceltem 

M 

s 

Traceltem 

dsa 

M 

s 

targetObject 

G 

s 

operationProgress 

M 

s 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

G 

s 
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Table  11.5.  DSP  Protocol  Support  (Part  9  of  9) 


Protocol  Element 

Support 
Classification 

Comments 

Request 

Response 

ContinuationReference 

targetObject 

S 

M 

aliasedRDNs 

S 

G 

operationProgress 

S 

M 

nameResolutionPhase 

S 

M 

nextRDNToBeResolved 

S 

G 

rdnsResolved 

S 

G 

reference  Type 

S 

G 

AccessPoint 

S 

M 

AccessPoint 

Name 

S 

M 

PresentationAddress 

s 

M 

pSelector 

s 

G 

sSelector 

s 

G 

tSelector 

s 

G 

nAddress 

s 

M 

Notes  for  table  11.5 

1.  The  support  classification  is  G  when  supporting  the  chained  mode  of  interaction. 

2.  Some  of  these  operations  may  be  necessary  to  support  distributed  authentication. 
This  requirement  is  distinct  from  support  for  chained  mode  of  interaction. 
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Table  11.6.  DAP  Support  for  Digital  Signature  Protocol  Conformance  Profile. 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

Security  Parameters 

certification-path 

G 

S 

name 

G 

S 

time 

G 

S 

random 

G 

S 

target 

G 

S 

requestor 

G 

S 

CormnonResults 

Security  Parameters 

S 

G 

performer 

S 

G 

Table  11.7.  DSP  Support  for  Digital  Signature  Protocol  Conformance  Profile. 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

-  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

Security  Parameters 

certification-path 

G 

S 

name 

G 

S 

time 

G 

S 

random 

G 

S 

target 

G 

S 

requestor 

G 

S 

CommonResults 

Security  Parameters 

G 

s 

performer 

0 

G 
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Table  11.8.  T~)AP  Support  for  Strong  Authentication  Protocol  Conformance  Profile. 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

DirectoryBind  Argument 

M 

s 

credentials 

G 

S 

simple 

G 

S 

name 

G 

S 

validity 

G 

s 

password 

G 

s 

strong 

certification-path 

G 

s 

bind-token 

G 

s 

externalProcedure 

0 

o 

versions 

O 

s 

DirectoryBind  Result 

S 

G 

credentials 

S 

G 

simple 

s 

G 

name 

s 

G 

vahdity 

s 

G 

password 

s 

G 

strong 

s 

G 

certification-path 

s 

G 

bind-token 

s 

G 

externalProcedure 

0 

O 

versions 

s 

0 

11  -  59 


December  '89 


Table  11.9.  DSP  Support  for  Strong  Authentication  Protocol  Conformance  Profile. 


Protocol  Element 

Support 
Classification 

Comments 

DUA 

DSA 

DirectoryBind  Argument 

M 

s 

J        i.  *  1 

credentials 

/-I 

simple 

G 

s 

G 

S 

validity 

G 

S 

password 

G 

S 

strong 

certification-path 

G 

S 

bind-token 

G 

s 

externalProcedure 

0 

o 

versions 

0 

S 

DirectoryBindResult 

S 

G 

credentials 

S 

G 

simple 

S 

G 

name 

s 

G 

validity 

s 

G 

password 

s 

G 

strong 

s 

G 

certification-path 

s 

G 

bind-token 

s 

G 

externalProcedure 

0 

O 

versions 

s 

O 
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Table  11.10.  Error  Symptoms  (Part  1  of  3) 


Symptom 

Descriptor! 

E_ACCESS 

The  initiator  has  insufficient  access  rights  to  carry  out  this  operation. 

E_ADMIN_LIMIT 

The  Directory  heis  reached  some  Umit  set  by  an  administrative  authority, 
and  no  partial  results  are  available  to  return  to  the  user. 

E_ALIAS_DEREF 

One  of  three  situations  exists: 

1.  An  alias  has  been  encountered  while  a  previous  alias  was  being  deref- 
erenced, or 

2.  a  name  contained  an  alieis  plus  one  or  more  additional  RDNs  when 
the  dontDereferenceAliases  service  control  was  being  used,  or 

3.  the  name,  supphed  in  an  operation  that  precludes  alias  dereferencing,^ 
contained  an  alias  plus  one  or  more  additional  RDNs.  ** 

E-ALIAS-LOOP 

During  a  whole-subtree  search  operation,  an  alias  has  been  encountered 
which  would  lead  to  a  loop  (i.e.,  the  alias  points  to  an  entry  which  is 
superior  to  entries  which  have  already  been  evaluated  in  earring  out  the 
search). 

E_ALIAS_PROBLEM 

An  aUas  has  been  encountered,  but  the  entry  to  which  it  points  does  not 
exist. 

E_ARG_BOUNDS 

The  argument  does  not  comply  with  pragmatic  constraints  (defined  locally 
or  by  functional  standards). 

E_ARG^YNTAX 

An  operation  argument  either  has  incorrect  ASN.l  encoding  or  it  has  cor- 
rect ASN.l  encoding,  but  does  not  comply  to  the  syntax  as  defined  in  the 
Directory  Documents.  Note: 

1.  Within  BindArgument,  additional  elements  are  permitted,  to  allow 
future  extensions,  and  do  not  create  an  error  situation. 

2.  Errors  within  attribute  values  are  not  included  in  this  codification 
(see  E_ATT^YNTAX). 

E_ARG_VIOL 

An  operation  argument  has  correct  syntax,  but  it  violates  additional  rules 
and  constraints  levied  by  the  Directory  Documents  (e.g.,  use  of  a  Priority 
integer  value  whose  meaning  is  undefined).  Note: 

1.  Within  a  Relative  Distinguished  Name,  having  two  AVAs  of  the  same 
attribute  type  is  an  error  which  is  covered  by  E_DN,  and  not  by 
EJ\.RG-VIOL. 

2.  Errors  within  attribute  values  are  not  included  in  this  codification 
(see  E-ATT^YNTAX). 

E_ATT_BOUNDS 

An  attribute  value  does  not  comply  with  bounds  specified  either  by  the 
Directory  Documents  or  by  functional  standards. 

E-ATT.OR.VALUE_EXISTS 

Within  an  entry,  an  attribute  or  attribute  value  already  exists,  causing  an 
error  situation. 
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Table  11.10.  Error  Symptoms  (Part  2  of  3) 


Symptom 

Descriptor! 

EJVTT^YNTAX 

An  attribute  value  either  has  incorrect  ASN.l  encoding  or  it  has  correct 
ASN.l  encoding  but  does  not  comply  witht  the  ASN.l  encoding  defined  by 
the  attribute  type. 

EJITT.VALUE 

An  attribute  value,  although  of  correct  ASN.l  encoding,  and  conformant 
with  the  syntax  defined  for  the  attribute  type,  is  not  compliant  with  other 
rules  (e.g.,  a  non-ISO  3166  country  name  encoding). 

E_ACCESS 

The  initiator  has  insufficient  access  rights  to  carry  out  this  operation. 

EJ\.UTHENTICATI0N 

The  authentication  offered  does  not  match  that  required  by  the  object  being 
authenticated. 

E3USY 

The  DSA  is  unable  to  handle  this  operation  at  this  time  (but  it  may  be 
able  to  do  so  after  a  short  while). 

E.CHAIN 

The  DSA  needs  to  use  chaining  to  carry  out  this  operation,  but  is  prohibited 
from  doing  so  by  Service  Controls. 

E-CREDENTIALS 

The  credentials  offered  do  not  match  those  of  the  object  with  which  au- 
thentication is  taking  place. 

EJDBE 

An  inconsistency  has  been  detected  in  the  DSA's  data  base,  which  may  be 
localized  to  a  particular  entry  or  set  of  entries. 

EJDIT-STRUCTURE 

An  attempt  was  made  via  an  add  operation  to  to  place  an  entry  in  the  DIB 
whose  object  class  would  violate  the  DIT  structure  rules. 

EJDN 

A  DN  contains  an  RDN  with  two  AVAs  of  the  same  attribute  type. 

E_DSA 

A  DSA  to  which  chaining  is  taking  place  is  unable  to  respond. 

ej;ntry_exists 

An  entry  of  the  given  name  already  exists,  causing  an  error. 

E_EXTENSION 

A  DSA  was  unable  to  satisfy  a  request  because  one  or  more  critical  exten- 
sions were  not  available. 

ejllegal_root.obj 

Root's  DN  hcis  been  supplied  as  the  object  of  a  Read,  Compare,  AddEntry, 
RemoveEntry,  ModifyEntry,  Modify  RDN,  or  as  the  Base  Object  of  a  smgie 

ICVCl  oCalCll. 

EJLLEGAL_ROOT.VAL 

Root's  DN  has  been  supplied  illegally  as  an  attribute  value  (e.g.,  as  an 
Aliased  Object  Name). 

EJLOOP 

A  loop  has  been  detected  in  the  knowledge  information  within  the  system. 

E_MATCH 

ine  attribute  specified  does  not  support  the  required  matching  capability. 

E_MISSING_AVA 

When  creating,  or  after  modifying,  an  entry,  an  AVA  in  the  entry's  RDN 
is  not  represented  within  the  entry's  set  of  attributes. 

E_MISSING.OBJECT-CLASS 

When  creating  an  entry,  the  entry  does  not  possess  an  object  class. 

E_MULTI_DSA 

The  operation  is  an  update  operation  which  affects  other  DSAs. 

E_NAMING.VIOLATION 

The  name  of  the  new  or  modified  entry  is  incompatible  with  its  object  class. 

E_NONXEAF  .OPERATION 

The  operation  being  attempted  is  illegal  except  on  a  leaf. 

EJ^JONNAMINGjVTTRIBUTE 

In  either  an  add  or  ModifyRDN  operation,  an  attribute  is  included  in  the 
last  RDN  that  is  not  a  valid  naming  attribute  according  to  the  DIT  struc- 
ture rules. 
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Table  11.10.  Error  Symptoms  (Part  3  of  3) 


Symptom 

Descripton 

E3rOT.SINGLE.VALUED 

An  attribute,  registered  as  single-valued,  has  been  found  with  more  than 
one  value. 

EJ^O..SUCH_ATT 

The  specified  attribute  has  not  been  found. 

E_NOjSUCH.OBJECT 

The  specified  entry  has  not  been  found. 

EJ^O^UCH.VALUE 

The  specified  attribute  value  has  not  been  found. 

E.OBJECT.CLASS_MOD 

An  (illegal)  attempt  has  been  made  to  alter  or  remove  an  object  class 
attribute. 

E-OBJECT_CLASS_VIOL 

There  is  a  schema  violation  (e.g.,  missing  mandatory  attribute,  or  non- 
allowed  attribute  present). 

E_REFERENCE 

An  erroneous  reference  has  been  detected  (e.g.,  DSA  cannot  handle  name 
even  as  far  as  the  number  of  RDNs  that  have  already  been  resolved). 

E-SCOPE 

No  referrals  were  available  within  the  requested  scope. 

E.SYSTEM_PERM 

A  serious  and  permanent  software  or  system  error  has  been  detected  which 
prevents  completion  of  the  operation. 

E_SYSTEM_TEMP 

A  serious  but  temporary  software  or  system  error  has  been  detected  which 
prevents  completion  of  the  operation. 

E.TIMEOUT 

The  operation  has  not  completed  within  the  allotted  time. 

E.UNABLE_TO.COMPLETE 

The  DSA  is  unable  to  complete  this  operation,  or  others  like  it  (this  applies 
particularly  to  search). 

E.UNABLE_TO_PROCEED 

The  DSA  cannot  satisfy  the  operation  after  receiving  it  on  the  basis  of  a 
valid  non-specific  subordinate  reference. 

E_UNDEFINED_ATT 

An  unregistered  attribute  has  been  encountered. 

E.UNSUPPORTED.OC 

The  object  class  of  the  entry  is  not  supported  as  a  valid  object  class  for 
entries  within  this  DSA. 

E-VERSION 

An  unexpected  version  has  been  found  in  Bind. 

E.ZERO.VALUES 

An  attribute  has  been  found  (e.g.,  as  a  result  of  a  modify-entry  operation) 
with  no  values. 
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Table  11.11.  Error  Situations 


Situation 

Description 

RTND  T  or*  AT 

XJi.il  LJ- Lj  w  V_y >V Lj 

A  hinH  i<?  Kpinp^  attemnted*  either  the  entrv  named  is  for  should  be) 
within  a  local  naming  context,  or  name  resolution  is  being  carried 
out  on  the  part  of  the  name  that  is  known  locally. 

BIND-REMOTE 

A  bind  is  being  attempted,  and  the  entry  named  is  not  within 
a  local  naming  context;  remote  validation  of  credentials  is  being 
carried  out. 

NAME-RESOLUTION 

Name  resolution  is  being  carried  out. 

ADD-ENTRY-NAME-RESOLUTION 

During  an  add  entry  operation,  name  resolution  has  been  success- 
fully accomplished  on  the  superior  object,  and  is  not  being  carried 
out  to  determine  whether  the  new  entry  already  exists. 

ADD-ENTRY 

The  entry  is  being  generated. 

MODIFY-ENTRY 

The  entry  is  being  modified. 

MODIFY-RDN 

The  RDN  is  being  modified. 

REMOVE-ENTRY 

The  entry  is  being  removed. 

READ 

The  entry  is  being  read. 

COMPARE 

A  Compare  operation  is  being  carried  out  on  the  entry. 

LIST 

A  List  operation  is  being  carried  out  on  the  entry. 

SEARCH-FILTER 

A  Search  operation  is  being  carried  out;  the  filter  is  being  evaluated 
or  acted  upon. 

SEARCH-ENTRY 

A  Search  operation  is  being  carried  out;  the  required  entry  infor- 
mation is  being  evaluated  or  acted  upon. 

ABANDON 

An  Abandon  operation  is  being  carried  out. 

TRACE-EVALUATION 

The  trace  element  is  being  evaluated  for  loops. 
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Table  11.12.  Notation  Used  to  Describe  Error  Actions 


Error  Action 
Notation 


Meaning 


Rej 


A  reject  operation  is  generated,  with  problem  mistyped-argument. 


Ah[<  qualifier>) 


Abandon  Failed  Error  is  generated.    The  qualifier  may  take  on  values  codified  as 

follows: 


CA  —  Cannot  abandon 
TL     -  Too  late 


NSO  -  No  such  operation 


A{<  qualifier>) 


Attribute  Error  is  generated.  The  qualifier  ma,y  take  on  values  codified  as  follows: 


AVE  -  Attribute  or  value  already  exists 
IAS     —  Invalid  attribute  syntax 
NSA  -  No  such  attribute 


CV     -  Constraint  violation 
IM      -  Inappropriate  matching 
UAT  -  Undefined  attribute  type 


'N{<qualifier>) 


NameError  is  generated.  The  qualifier  may  take  on  values  codified  as  follows: 


ADP  -  Alias  dereferencing  problem 
IAS    -  Invalid  attribute  syntax 


AP  -  Alias  problem 
NSO  -  No  such  object 


SC{<  qualifier>) 


Security  Error  is  generated.  The  qualifier  may  take  on  values  codified  as  follows: 


lA      -  Inappropriate  authentication 
IC      -  Invalid  credentials 
NI      -  No  information 


lAR    —  Insufficient  access  rights 
IS      -  Invalid  signature 
PR     -  Protection  required 


S{<qualifier>] 


Service  Error  is  generated.  The  qualifier  may  take  on  values  codified  as  follows: 


ALE  - 

Administrative  limit  exceeded 

B 

Busy 

CR  - 

Chaining  required 

DE  - 

Dit  Error 

IR  - 

Invalid  reference 

LD  - 

Loop  detected 

COS  - 

Out  of  Scope 

TLE  - 

Time  limit  exceeded 

UA  - 

Unavailable 

UAP  - 

Unable  to  proceed 

UCE  - 

Unavailable  critical  extension 

UWP  - 

Unwilling  to  perform 

\J  {<  qualifier>) 


Update  Error  is  generated.  The  qualifier  Taa.y  take  on  values  codified  as  follows: 

AMD  -  Affects  multiple  DSA  EAE  -  Entry  already  exist 

NAN  -  Not  allowed  on  non-leaf  NAR  -  Not  allowed  on  RDN 

NV     -  Naming  violation  OCV  -  Object  class  violation 

OMP  -  Object  class  modification  prohibited 
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Situation  (See  Table  11.11) 

Symptom 

Bind- 

Add-Entry- 

(See  Table  11.10) 

Bind- 

Remote- 

Name- 

Name- 

Local 

Resolution 

Resolution 

Resolution 

Add-Entry 

Modaiy-nntry 

B_A.CCESS 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAK)(14) 

SO(iARj(14) 

E_ADMlNJjlMi  i 

S(UA) 

S(UA) 

S(ALE) 

S(ALE) 

O  /  AT  C»\ 

A  T  T  A  C  TM7*'D"C^T 

S(IC) 

S(IC) 

N(ADP) 

I?    ATTAC   J  r\C\X> 

Ci  _A  Jj  iA  o  _1j  U  U 

b -A.  L  lA  S  _r  K  O  B  Lh^M 

S(IC) 

S(IC) 

N(AP) 

_A  K  O -D  U  U  JN  U  o 

(8) 

b^U  Wr  ^^1^ ) 

(1) 

(1) 

Rej 

Rej 

Rej 

Rej 

E-ARG.VIOL 

(1) 

(1) 

Rej 

Rej 

Rej 

Rej 

EJ^TT30UNDS 

SC(IC) 

(7) 

N(IAS) 

N(IAS) 

A(CV) 

A(CV) 

E_A.TT.OR-VALUEj;XISTS 

A(AVE) 

A(AVE) 

EJVTT^YNTAX 

SC(IC) 

(7) 

N(IAS) 

N(IAS) 

A(IAS) 

A(IAS) 

EJ^TT.VALUE 

SC(IC) 

(7) 

N(IAS) 

N(IAS) 

A(IAS) 

A(IAS) 

EJ^UTHENTICATION 

SC(IA) 

SC(IA) 

E3USY 

S(UA) 

S(UA) 

S(B) 

S(B) 

S(B) 

S(B) 

E-CHAIN 

S(CR) 

E.CREDENTIALS 

SC(IC) 

SC(IC) 

EJDBE 

S(UA) 

S(UA) 

S(DE) 

S(DE) 

S(DE) 

S(DE) 

EJJITJSTRUCTURE 

U(NV) 

EJ)N 

SC(IC) 

SC(IC) 

N(NSO) 

C(NV) 

E_DSA 

S(UA) 

S(UA) 

S(UA) 

EJENTRYJ:XISTS 

U(EAE) 

E-EXTENSION 

S(UWP) 

S(UCE) 

S(UCE) 

S(UCE) 

EJLLEGALJIOOT-OBJ 

SC(IC) 

SC(IC) 

N(NSO) 

N(NSO) 

N(NSO) 

EJLLEGALJIOOT-VAL 

SC(IC) 

(7) 

N(IAS) 

N(IAS) 

A(IAS) 

A(IAS) 

E_LOOP 

S(UA) 

S(LD) 

11  -  66 


September  1990  (Stable) 


Table  11.13.  Error  Actions  (Part  2  of  6) 


Situation  (See  Table  11.11) 

Symptom 

Bind- 

Add-Entry- 

(See  Table  11.10) 

Bind- 

Remote- 

Name- 

Name- 

Local 

Resolution 

Resolution 

Resolution 

Add-Entry 

Modify-Entry 

E^ATCH 

SC(IC) 

SC(IC) 

A(IM) 

A(IM) 

A(IM) 

E.MISSING_AVA 

U(NAR) 

U(NAR) 

EJ^ISSING.OBJECT-CLASS 

U(OCV) 

U(OMP) 

EJklULTLDSA 

S(AMD) 

E_NAMING-VIOLATION 

U(NV) 

E_NON.LEAF.OPERATION 

E_NONNAMING.ATTRIBUTE 

U(NV) 

E_NOT.SINGLE.VALUED 

A(CV) 

A(CV) 

EJJfO-SUCH.ATT 

A(NSA) 

EJ^O-SUCH-OBJECT 

SC(IC) 

SC(IC) 

N(NSO) 

E-NO-SUCH.VALUE 

A(NSA) 

E.OBJECT.CLASSJvIOD 

U(OMP) 

E.OBJECT.CLASS.VIOL 

U(OCV) 

U(OCV) 

EJIEFERENCE 

S(UA) 

S(IR) 

E^COPE 

S(OOS) 

E^YSTEMJ'ERM 

S(UA) 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

EJSYSTEM.TEMP 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

E.TIMEOUT 

S(UA) 

(9) 

S(TLE) 

S(TLE) 

S(TLE) 

S(TLE) 

E.UNABLE.TO.COMPLETE 

E.UNABLE.TOJ'ROCEED 

(2) 

(2) 

E.UNDEFINED_A.TT 

SC(IC) 

(3) 

U(NV) 

A(UAT) 

A(UAT) 

E.UNSUPPORTED-OC 

U(OCV) 

E.VERSION 

S(UA) 

EJERO-VALUES 

A(CV) 

A(CV) 
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^vm  Fit  nm 
(See  Table  11  101 

Situation  (See  Table  11.11) 

RDN 

IVCIIIUVC— 

Entry 

Read 

Compare 

Trace- 
Evaluation 

E_A.CCESS 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

E_A,DMINJL,IMIT 

S(ALE) 

S(ALE) 

E_A.LIAS_DEREF 

E_A.LIASJjOOP 

E_A.LIAS-PROBLEM 

E-ARG^OUNDS 

S(UWP)(12) 

S(UWP)(12) 

EJ^RGJSYNTAX 

Rej 

Rej 

Rej 

EJ\.RG.VIOL 

Rej 

Rej 

Rej 

Rej 

E-ATT -BOUNDS 

N(IAS) 

A(CV) 

(7) 

E-ATT.OR.VALUE.EXISTS 

EJ^TTJSYNTAX 

N(IAS) 

A(IAS) 

(7) 

E-ATT.VALUE 

N{IAS) 

A(IAS) 

(7) 

E_A.UTHENTICATION 

E_BUSY 

S(B) 

S(B) 

S(B) 

S(B) 

E.CHAIN 

E.CREDENTIALS 

EJ)BE 

S(DE) 

S(DE) 

S(DE) 

S(DE) 

EJ5ITJSTRUCTURE 

EJDN 

A(CV) 

A(IAS) 

EJDSA 

E^NTRY.EXISTS 

U(EAE) 

E_EXTENSION 

S(UCE) 

S(UCE) 

S(UCE) 

S(UCE) 

EJLLEGALJIOOT-OBJ 

N(NSO) 

N(NSO) 

N(NSO) 

N(NSO) 

EJLLEGAL-ROOT-VAL 

N(IAS) 

A(IAS) 

(7) 

E-LOOP 
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Symptom 
(See  lable  11.10) 

Situation  (See  Table  11.11) 

Modify- 
RDN 

Remove- 
Entry 

Read 

Compare 

Trace- 
Evaluation 

E_MATCH 

A(IM) 

A(IM) 

(7) 

E -MIS  S  IN  G -A.  V  A 

E_MISSING_OBJECT_CLASS 

E_MULTI_DSA 

S(AMD) 

S(AMD) 

EJnAMING-VIOLATION 

U(NV) 

E_NON-LEAF-OPERATION 

T  T/XT  A  XT  \ 
U(N  AN) 

T  T  /  XT  A  XT\ 
U(N  AN) 

E_NCT-SINGLE.VALUED 

A(CV) 

E-NO-SUCH-ATT 

A(NSA)(4) 

A(NSA)(4) 

E_NO.SUCH.OBJECT 

EJ^O.SUCH.VALUE 

E-OBJECT-CLASSJVIOD 

E.OBJECT.CLASS.VIOL 

U(OCV) 

EJIEFERENCE 

EJSCOPE 

E^YSTEMJERM 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

E^YSTEM.TEMP 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

E.TIMEOUT 

S(TLE) 

S(TLE) 

S(TLE) 

S(TLE) 

E.UNABLE.TO.COMPLETE 

E.UNABLE.TO.PRCCEED 

E.UNDEFINED.ATT 

A(UAT) 

A{NSA)(4) 

A(NSA) 

(7) 

E.UNSUPPORTED-OC 

E-VERSION 

EJZERO.VALUES 

(11) 
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Situation  (See  Table  11.11) 

Symptom 

(See  Table  11.10) 

List 

Search 

Seeirch 

(Filter) 

(Filter) 

Entry 

Abandon 

EJVCCESS 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

E^DMINXIMIT 

S(ALE)(13) 

S(ALE)(13) 

S(ALE)(13) 

E_A.LIASJDEREF 

(5) 

E_ALIAS_LOOP 

(5) 

EJ^LIAS_PROBLEM 

(5) 

EJ^.RG^OUNDS 

S(UWP)(12) 

S(UWP)(12) 

S(UWP)(12) 

EJVRG^YNTAX 

Rej 

Rej 

Rej 

Rej 

E-ARG.VIOL 

Rej 

Rej 

E-ATTJ30UNDS 

A(CV) 

E_ATT-OR.VALUE-EXISTS 

EJiiTT -SYNTAX 

A(IAS) 

EJ^TT.VALUE 

A(IAS) 

E_AUTHENTICATION 

E_BUSY 

S(B) 

S(B) 

S(B) 

E.CHAIN 

E.CREDENTIALS 

EJDBE 

S(DE) 

S(DE) 

S(DE) 

E_DIT.STRUCTURE 

EJDN 

A(IAS) 

EJDSA 

(5) 

EJ}NTRY.EX1STS 

ej:xtension 

S(UCE)(13) 

S(UCE)(13) 

S(UCE)(13) 

EJLLEGAL_ROOT.OBJ 

(10) 

EJ[LLEGAL_ROOT-VAL 

A(IAS) 

EXOOP 

(5) 
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Table  11.13.  Error  Actions  (Part  6  of  6) 


Symptom 
(See  Table  11.10) 

Situation  (See  Table  11.11) 

List 
(Filter) 

Search 
(Filter) 

Search 
Entry 

Abandon 

EJ^ATCH 

A(IM) 

EJvIISSINGJVVA 

EJvIISSING-OBJECTXLASS 

E_MULTI_DSA 

E_NAMING.VIOLATION 

E_NON-LEAF.OPERATION 

E_NONNAMING-ATTRraUTE 

E_NOT-SINGLE.  VALUED 

E_NO.SUCH.ATT 

EJ40.SUCH.0BJECT 

EJ40.SUCH- VALUE 

E.OBJECT.CLASS_M0D 

E.OBJECT-CLASS-VIOL 

EJIEFERENCE 

E.SCOPE 

EJSYSTEM.PERM 

S(UWP) 

S(UWP) 

S(UWP) 

Ab(CA) 

E.SYSTEM.TEMP 

S(UA) 

S(UA) 

S(UA) 

Ab(CA) 

E.TIMEOUT 

S(TLE)(13) 

S(TLE)(13) 

S(TLE)(13) 

E.UNABLE.TO.COMPLETE 

S(B) 

S(B) 

S(B) 

Ab(CA) 

E.UNABLE.TO.PROCEED 

E.UNDEFINED.ATT 

(6) 

(6) 

E.UNSUPPORTED-OC 

E.VERSION 

E.ZERO-VALUES 
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Notes  for  table  11.13 

1.  Use  A-U-ABORT.  Note,  however,  that  extra  elements  are  permitted  here. 

2.  An  "unable-to-proceed"  error  becomes  SC(IC)  for  bind  and  N(NSO)  for  operations 
if  no  DSA  contacted  can  located  the  object. 

3.  An  undefined  attributed  encountered  during  name  resolution  is  ordy  an  error  - 
N(NSO)  -  if  the  entry  is  identified  as  local.  See  also  Note  10  below. 

4.  The  A(NSA)  condition  is  reserved  in  the  case  of  "read"  for  the  situation  when  no 
attribute  of  the  specific  list  provided  can  be  returned  (for  re<isons  that  include  security 
errors). 

5.  Any  fsdlure  to  propagate  a  search  causes  abandonment  of  that  part  of  the  search. 

6.  Undefined  attributes  are  regarded  as  not  matched  or  found,  but  cause  no  errors  in 
search. 

7.  This  error,  if  detected,  should  be  ignored;  processing  continues. 

8.  This  error  would  occur  as  a  result  of  a  bind  argument  with  a  name  containing  too 
many  RDNs  for  the  DSA.  Use  either  S(UA)  or  S(IC). 

9.  DSAs  should  use  the  time-limit  service  control  with  local  timeout  to  limit  the  remote 
validation  of  credentials;  if  the  operation  fails  as  a  result,  S(UA)  is  used. 

10.  For  a  single-entry  search,  N(NSO)  may  be  used. 

11.  Either  the  whole  attribute  should  be  removed,  or  the  deleteOldRDNflag  should  be 
ignored. 

12.  Wherever  S(UWP)  appears  in  the  above  tables  beside  E_ARG_BOUNDS,  a  ROSE 
"Rej"  is  also  admissible. 

13.  The  error  is  returned  when  there  are  no  partial  results,  otherwise  a  partialOutcome- 
Qualifier  with  the  appropriate  limitProblem  is  returned  (cf  Directory  Documents,  Part 
3,  item  g  of  clause  12.8.2,  and  Part  3,  clause  10.1.3.3.1). 

14.  In  every  case  where  a  security  error  occurs,  except  in  bind,  SC(NI)  may  be  used 
in  place  of  the  specified  problem,  to  support  a  Security  Policy  which  states  that  no 
information  on  the  problem  may  be  divulged.  In  the  case  of  the  bind,  SC(NI)  is  not 
available. 
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12.  SECURITY 

The  Security  Architecture  specified  in  ISO  7498/Part  2  -  Security 
Architecture  (as  presented  in  ISO/TC  97/SC  21/N1528)  shall  be  used  as  a 
basis  for  further  work  in  the  Special  Interest  Group  on  Security. 

The  security  services  that  are  to  be  implemented  first  shall  include 
confidentiality,  integrity,  authentication  and  access  control.  Non- 
repudiation  of  the  source  shall  also  be  included  for  consideration  for 
implementation.  These  services  are  defined  and  discussed  in  more  detail 
in  ISO  7498/Part  2  -  Security  Architecture. 


12 . 1  Definitions 

The  following  definitions,  based  on  the  definitions  in  ISO  7498/Part 
2,  are  to  be  used  when  interpreting  chapter  12. 


Access  Control: 


The  provision  of  a  security  system 
that  establishes  and  enforces  which 
users  or  processes  can  get  access 
to  what  data  or  processing 
facilities . 


Authentication 
Information: 


Information  used  to  establish  the 
validity  of  a  claimed  identity. 


Authorization: 
Confidentiality: 


The  granting  of  access  rights. 

A  security  service  that  protects 
data  from  unauthorized  disclosure. 


Connection: 


A  state  of  communication  that 
exists  between  two  communicating 
entities  by  establishing  an 
association  between  them,  providing 
one  or  more  data  paths  between  them 
allowing  sequential  transfers  of 
data,  and  then  terminating  the 
association . 


Connectionless : 


A  state  of  communication  that 
provides  transfer  of  data  from  one 
entity  to  another  without  a 
preestablished  association. 


Data  Integrity: 


The  property  that  data  has  not  been 
altered  or  destroyed  in  an 
unauthorized  manner. 
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Data  Origin 
Authentication: 


The  corroboration  that  the  source 
of  data  received  is  as  claimed. 


Digital  Signature; 


Peer-entity 
Authentication: 


Data  that  allows  a  recipient  of 
information  to  verify  the  source 
and  integrity  of  the  information. 


The  corroboration  that  peer 
entities  in  an  association  are  as 
claimed. 


Repudiation: 


Denial  by  one  or  both  of  the 
entities  of  an  association  of 
having  participated  in  all  or  part 
of  the  association  or 

communication  of  the  association. 


Selective  Field 
Protection: 


The  protection  of  specified  fields 
of  data  in  a  communication. 


Traffic  Analysis 


Traffic  Flow 
Confidentiality: 


The  inference  of  information  from 
observation  of  traffic  flow  in 
communications  (presence,  absence, 
amount,  direction  and  frequency). 


A  confidentiality  service  to 
protect  against  traffic  analysis. 


12 . 2  Matrix  of  Security  Services  and  OSI  Layers 

The  following  matrix  shows  the  layers  of  the  OSI  architecture  at  which 
certain  security  services  are  considered  to  be  desirable.  The  entries 
in  the  matrix  are  "H"  for  high  level  of  desirability,  "M"  for  medium 
desirability,  and  "L"  for  low  level  of  desirability.  No  entry  in  the 
matrix  means  that  the  service  is  not  considered  desirable.  This 
matrix  was  produced  from  a  similar  matrix  in  ISO  7498/Part  2  which 
showed  the  layers  of  the  architecture  that  could  be  used  to  provide 
the  security  service.  The  level  of  desirability  was  established  by 
the  members  of  the  Special  Interest  Group  in  Security  of  the  OSI 
Implementors  Workshop. 


Note:  The  Matrix  is  a  consensus  of  the  opinions  of  the  members  as  to 
where  selected  security  services  should  be  placed.      It  should  not  be 
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considered  restrictive  and  interpreted  as  meaning  that  the  security 
services  cannot  be  placed  elsewhere  in  the  OSI  architecture  or  have 
other  implementation  priorities.  This  will  depend  upon  the  differing 
security  needs  of  specific  applications.  Also,  it  should  not  be 
considered  complete  in  that  other  security  services  may  exist  that 
should  be  incorporated  in  the  architecture. 


Table  12.1.     OSI  Layers  Desirable  for  Placing  Security 


SERVICE 

1 

2 

3 

4 

5 

6 

7 

1 

(a) 

Peer  entity  authentication 

L 

H 

H 

(b) 

Data  origin  authentication 

L 

L 

H 

2 

Access  Control  Service 

M 

M 

H 

3 

(a) 

Connection  confidentiality 

L 

L 

L 

H 

H 

H 

(b) 

Connectionless  confidentiality 

L 

H 

L 

H 

H 

(c) 

Selective  field  confidentiality 

H 

H 

(d) 

Traffic  flow  confidentiality 

M 

L 

L 

4 

(a) 

Connection  integrity  with  recovery 

H 

L 

(b) 

Connection  integrity  without  recovery 

N 

N 

N 

(c) 

Selective  field  connection  integrity 

N 

(d) 

Connectionless  integrity 

H 

L 

L 

(e) 

Selective  field  connectionless  integrity 

H 

5 

(a) 

Non-repudiation:  originator 

L 

(b) 

Non-repudiation:  receiver 

L 

Implementation  priority:        H  (high) 

M  (medium) 
L  (Low) 

N  (No  Priority) 

Table  1.     ISO  7498/Part  2:     Security  Addendum  --     NIST/OSI  Workshop 
Summary   Of    SIG-SEC    Discussions    of    Security    Service    Placement,  May, 
1987 

Notes:  The  following  notes  are  for  explanation  of  the  above  matrix  and 
comments , 

A   security    system   should   be    considered    to   be   an    integrated   set  of 


12-3 


December  '89 


security  services  that  are  placed  at  selected  OSI  layers.  The 
services  should  be  selected  based  on  a  risk  analysis  for  the  computer 
system  being  protected.  Security  mechanisms  must  be  then  chosen  that 
will  provide  the  security  services  and  incorporated  in  the  software 
and  hardware  of  the  computer  system  and  controlled  by  the  OSI  software 
and  hardware  at  the  selected  layer ( s) . 

For  example,  authentication,  access  control,  confidentiality  and 
integrity  are  selected  as  the  major  security  goals  for  an  OSI  system. 
A  connection  oriented  transport  protocol  is  being  implemented.  An 
example  of  the  use  of  the  Matrix  could  be  in  an  electronic  mail 
system,  to  illustrate  this  the  following  specific  services  and  layers 
were  chosen: 

Peer  entity  authentication:  Layer  4 
Data  origin  authentication:     Layer  7 

Access  Control:     Layer  7 

Connection  confidentiality:     Layer  4 
Selective  field  confidentiality:     Layer  7 

Connection  integrity  with  recovery:     Layer  4 
Connectionless  integrity:     Layer  7 

The  layer  7  services  were  chosen  to  support  the  mail  system  that  would 
protect  the  selective  paragraphs  of  an  electronic  message  as  directed 
by  the  user.  A  mail  system  is  considered  connectionless.  Access 
control  is  a  function  of  only  layer  7. 

The  layer  4  services  were  chosen  to  provide  a  reliable  transport 
service  from  the  sender  to  the  intended  receive  of  the  electronic 
message.  A  full  connection  integrity  and  confidentiality  service  with 
peer  entity  authentication  will  assure  that  all  information  gets  to 
the  receiver  correctly  and  confidentially. 

Note:  The  security  protocols  and  mechanisms  that  provide  these 
services  are  beyond  the  scope  of  this  chapter  at  this  time.  The 
mechanisms  and  standards  for  their  interoperability  are  presently 
being  defined  and  will  be  added  to  this  chapter  as  they  become 
available . 
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UL  FUTURE  SECURITY 

Editor's  Note:  This  section  is  reserved  for  future  stable 
Security  Architecture  Agreements.  These 
agreements  may  be  found  in  the  aligned  section  of 
the  Working  Implementation  Agreements  Document. 
When  these  agreements  become  stable,  they  will  be 
moved  into  this  section  13  of  this  document. 
Consult  section  13  of  the  Working  Agreements 
Document  for  current  information. 
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14.  ISO  VIRTUAL  TERMINAL  PROTOCOL 


14. 1  INTRODUCTION 

The  NIST/OSI  Workshop  Virtual  Terminal  (VT)  SIG  is  making 
implementation  agreements  for  the  OSI  Basic  Class  VT  Service  and 
Protocol,  ISO  9040  and  ISO  9041. 

These  implementation  agreements  fall  into  the  following  categories. 

o        Functionality   to  be   implemented,    i.e.,,    functional  units, 
etc . 

o        Identification    and    specification    of    VT    profiles    to  be 
supported  by  conforming  implementations. 


o        Agreements     with     regard     to     implementation     issues  not 
specified  in    ISO  9040  and  ISO  9041. 

o       Resolution    of    problems    with        ISO    9040    and    ISO  9041 
identified  during  implementation. 

o        Statement    of    requirements    to    meet    conformance    to  these 
agreements . 


14.2  SCOPE  AND  FIELD  OF  APPLICATION 


14. 2 . 1        Phase  la  Agreements 

The  Telnet  profile  is  intended  to  support  the  following  usage: 

o        a    simple    line    at    a    time    or    character    at    a  time 
dialogue ,  and 

o        an  application  level  gateway  supporting  Internet  Telnet 
and  ISO  VTP  interoperation. 

The  Transparent  profile  supports  the  exchange  of  uninterpreted 
sequences  of  characters.  This  includes  support  of  VT-users  who 
wish  to  control  terminals  directly  through  the  use  of  embedded 
control  characters  and  escape  sequences. 

14 . 2 ■ 2        Phase  lb  Agreements 

The  Forms  profile  is  intended  to  support  forms -based  applications 
with  local  entry  and  validation  of  data  by  the  terminal  system. 
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This  profile  is  now  aligned  with  the  EWOS  VT  EG  Functional 
Standard. 

14 . 2 . 3        Phase  II  Agreements 

The  X.3  profile  supports  functionality  similar  to  the  CCITT 
recommendations  and  could  be  used  to  implement  an  X.3  to  ISO-VT 
gateway. 

See  Working  Agreements  regarding  Page  profiles. 

14.3  STATUS 

14 . 3 . 1  Status  of  phase  la 

Phase  la  of  the  VT  Agreements  was  stabilized  May  5,  1988.  This 
phase  covers  the  Telnet  and  Transparent  profiles.  No  future 
enhancements  will  be  made  to  this  phase. 

14.3.2  Status  of  phase  lb 

Phase  lb  of  the  VT  Agreements  was  first  stabilized  December  16, 
1988.  This  phase  covers  the  Forms  profile.  Alignment  with  EWOS 
required  substantial  modifications  which  were  ratified 
September  15,  1989. 

14 . 3 . 3  Status  of  phase  II 

Phase  II  is  still  in  progress  and  includes  the  remaining  profile 
work  for  Scroll,  Page  (S-mode)  and  Page  (A-mode)  profiles. 

The  X.3  profile  of  phase  II  was  stabilized  December  15,  1989. 

14.4  ERRATA 

Editor's  Note:  "Defect  Report"  material  may  be  included  here, 
including  versions  of  implementor  agrements  to  which  it 
applies . 

TECHNICAL 

06/90-1  Forms  Profile.  The  "FEICO  Update  Syntax"  ASN.l  comment 
which  follows  the  definition  of  the  PriValue  type  was 
corrected  to  support  multi-octet  repertoires. 

06/90-2  Forms  Profile.  The  descriptive  text  for  the  Field 
Entry     Instruction    Violation    FEE    was     corrected  to 
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indicate  that  both  an  entry- control  index  and  a  FEPR 
index  are  required  to  identify  the  FEPR  concerned. 

06/90-3  Forms  Profile.  The  descriptive  text  and  update  syntax 
for  the  Violation  FEC  were  corrected  to  indicate  that 
both  a  FEICO-name  and  an  index  are  required  to  identify 
a  FEIR. 

06/90-4  Forms  Profile.  The  update  syntax  for  the  writeString 
FER  was  corrected  to  align  with  the  descriptive  text 
for  this  FER. 


06/90-5  Forms  Profile.  The  descriptive  text  for  the  repertoire 
assignment  profile  argument  was  corrected  to  properly 
identify  the  default  value  as  the  GL  set  ISO  2375  Reg. 
No.   6  (ASCII). 

06/90-6  Forms  Profile.  The  concept  of  a  "current  keystroke" 
was  inserted  into  the  definition  of  the  FEICO  to  remove 
ambiguity  in  the  use  of  the  ST  and  UT  COs .  Various 
FEEs,  FECs  and  FERs  were  redefined. 


ALIGNMENT 


06/90-7  Forms  Profile.  A  definitive  note  was  added  to  define 
how  the  host  is  notified  of  the  current  entry  location 
when  data  entry  terminates  and  the  VTE-parameter 
access-outside-f ields  has  the  value  "allowed." 


06/90-8    Forms  Profile.     Three  font-assignment  profile  arguments 
were  added  to  accomodate  INTAP  requirements . 

09/90-1     Forms  Profile.     The  emphasis  subattribute  "h"  was  added 
with  values  "F"  (Framed)  and  "C"  (Encircled). 

09/90-2    Telnet      Profile.  Four      editorial     comments  were 

incorporated  to  align  with  the  corresponding  EWOS 
Functional  Standard. 


EDITORIAL 


06/90-9  Forms  Profile.  Two  definitive  notes  were  added  to 
clarify  the  secondary  attributes  comparison  mechanisms 
for  the  FEIs  and  FECs  that  test  equality  of  characters. 

06/90-10  Forms  Profile.  A  definitive  note  was  added  to  clarify 
the  effect  of  associating  multiple  Character-oriented 
FEIs  of  the  same  type  with  the  same  field. 
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06/90-11  Forms  Profile.  An  introductory  paragraph  in  the 
section  "Field  Entry  Condition  Definitions"  was 
rewritten  for  clarification, 

06/90-12  Forms  Profile.  The  descriptive  text  for  the  Write 
String  field  entry  reaction  was  modified  to  indicate 
precisely  how  and  where  the  associated  string  is  to  be 
written. 


09/90-3  X3  Profile.  The  reference  to  COs  P3  and  P4  contained 
in  comments  relating  to  DEVICE- 1  were  corrected  to 
reference  elements  3  and  4  of  the  PAD  CO. 


14.5  CONFORMANCE 


Conformant  VT  implementations  are  required  to  support  the  ISO  9041 
Clause  13  requirements  plus  the  additional  conformance  requirements 
identified  below. 


Figure  14.1  shows  conformance  status  for  VT  facilities  which  are 
optional  in  the  ISO  VT  standard.  The  terms  used  in  the  figure  are 
defined  as  indicated  below. 


o  "Mandatory"  indicated  the  facility  must  be  provided  by  all 
implementations  which  conform  to  these  agreements. 

o  "Optional"  indicates  that  the  VT  facility  is  not  required  to 
meet  minimum  conformance  requirements  but  has  been 
identified  as  providing  additional  useful  capabilities. 

o  "Profile  Dependent"  indicates  that  the  requirement  for  the 
facility,   if  any,   is  included  in  the  profile  definitions. 

o  "Not  Addressed"  indicates  that  the  VT  facility  is  outside 
the  scope  of  these  agreements. 
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Conformance  Status 

Mandatory 

Optional 

Profile 
Dependent 

Not 

Switch  Profile  ** 

X 

Multiple  Interaction 

ii  t;       u  i.  d  u  X  \j  11  ^ 

X 

^ o  ^ciccloti 

Y 
A 

UL^cllL.  L/ctL-d 

Y 
A 

Y 
A 

Y 
A 

Ejiuiaiiceci  riccess  K-iixes  ^ ^ 

Y 
A 

Y 
A 

Y 
A 

Fields  ** 

X 

RIOs  ** 

X 

S-mode 

X 

A-mode 

X 

Mode  Switching  Capability 

X 

Figure  14.1.     Conformance  Status  for  VT  Facilities. 


*It  is  not  anticipated  that  new  profiles  will  use  quarantined  delivery 
control . 

Functional  Units. 

For  each  mode  of  operation  (A-mode  and  S-mode)  which  is  implemented, 
the  default  profile  for  that  mode  as  defined  in  ISO  9040  must  be 
supported.  Implementations  that  support  A-mode  must  support  the  A- 
mode  default  profile  and  at  least  one  additional  Workshop  approved  A- 
mode  profile.  The  Transparent  profile  does  not  count  as  an  additional 
A-mode  profile.     Implementations  that  support  S-mode  must  support  the 
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S-mode  default  profile  and  at  least  one  additional  Workshop  approved 
S-mode  profile. 

For  each  profile  implemented,  VTE  parameter  ranges  or  values  specified 
in  the  Workshop-agreed  profile  and  associated  notes  must  be  supported. 

14.6  PROTOCOL        .  > 


14.6.1  Protocol  Elements 

All  protocol  elements  required  by  the  ISO  9040  VT  kernel  and 
Break  functional  units  are  selected. 

All  protocol  elements  required  by  the  Switch  Profile  functional 
unit  are  selected  if  this  functional  unit  is  used.  See  figure 
14.1. 

All  protocol  elements  required  by  the  Urgent  Data  functional  unit 
are  selected  if  this  functional  unit  is  used.     See  figure  14.1. 

14.6.2  Mapping  of  Protocol  Elements 

Mapping  of  protocol  elements  on  to  ACSE  or  Presentation  Seirvlces 
is  as  defined  in    ISO  9041. 


14.6.3        Protocol  Data  Unit  Structure 

Protocol  data  unit  structure  is  as  defined  in    ISO  9041. 


14 . 7  OIW  Registered  Control  Objects 

The  following  Control  Objects  are  used  by  more  than  one  profile.  Some 
of  the  CO  parameters  are  left  with  undefined  values  that  must  be 
assigned  by  the  profile  in  which  the  Control  Object  is  used. 

14.7.1         Sequenced  Application  (SA) 

This  is  a  Control  object  used  to  convey  signals  from  the 
application  to  the  terminal  in  sequence  with  other  updates. 

14 ■ 7 ■ 1  ■  1     Entry  Number 

To  be  supplied  by  Registration  Authority. 
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14.7.1,2     Name  of  Sponsoring  Body 

OSI  Impleraentors'   Workshop  (OIW) ,  VTSIG. 


14.7.1.3  Date 

The  date  of  submission  of  this  proposal  is  September  15, 
1989. 


14. 7 . 1 .4  Identifier 

oiw-vt-co-misc-sa  OBJECT  IDENTIFIER 
{ oiw-vt-co-misc  sa(0) ) 


14.7.1.5     Descriptor  Value 

"OIW  VT  CO  for  conveying  Sequenced  Application  Signals" 

14 . 7 ■ 1 ■ 6     CO  Parameters 

CO-structure  1 
CO-priority  "normal" 
CO-category  "symbolic" 
co-size  11 

14 . 7 . 1 ■ 7     CO  Values  and  Semantics 

The  following  table  lists  the  allowed  symbolic  values 
together  with  the  integers  used  to  reference  these  values  in 
the  ASN.l  update  syntax  of  ISO  9041: 

audible_alarm  0 

newlines_enabled  1 

newlines_disabled  2 

restore  3 

visuai_alarm  4 

keypad_enabled  5 

keypad_disabled  6 

keyboard_locked  7 

keyboard_unlocked  8 

device_disconnect  9 

break_signal  10 
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The  semantics  of  each  value  must  be  specified  in  the  VTE 
profile  which  references  this  CO, 

14.7.1.8  Additional  Information 
None 

14.7.1.9  Usage 
Defined  in  profile. 

14.7.2        Unsequenced  Application  (Vk) 

This  is  a  Control  object  used  to  convey  urgent  signals  from  the 
application  to  the  terminal. 

14. 7 . 2 ■ 1     Entry  Number 

To  be  supplied  by  Registration  Authority. 

14.7.2.2  Name  of  Sponsoring  Body 

OSI  Implementors'  Workshop  (OIW) ,  VTSIG. 

14.7.2.3  Date 

The  date  of  submission  of  this  proposal  is  September  15, 
1989. 

14.7.2.4  Identifier 

oiw-vt-co-misc-ua  OBJECT  IDENTIFIER: := 
{ oiw-vt-co-misc  ua(l)) 

14.7.2.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Unsequenced  Application  Signals" 
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14.7.2.6    CO  Parameters 


CO- structure 
CO-prlority 
co-category 
co-size 


1 

"urgent" 
"symbolic" 


11 


1^7. 2. 7    CO  Values  and  Semantics 
Same  as  in  SA. 

1^.7.2.9    Additional  Information 
None . 

14.7.2.?  V?w 
Defined  in  profile. 

14.7.3       Sequenced  Terminal  (ST^ 

A  keyboard  can  generate  many  signals  that  may  be  given  special 
meaning  to  the  application.  This  CO  is  general  enough  to  convey 
any  keyboard  event. 

14.7.3.1   Envry  l^m^^i 

To  be  supplied  by  Registration  Authority. 

14 . 7 ■ 3 . 2      Name  of  Sponsoring  Body 

OSI  Implementors  Workshop  (OIW) ,  VTSIG. 


The   date   of   submission   of   this   proposal    is   September  15, 


14.7.3.?  -Mis. 


1989. 
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14.7.3.4  Identifier 

oiw-vt-co-misc-st  OBJECT  IDENTIFIER  : := 
{oiw-vt-co-misc  st(2)} 

14.7.3.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Sequenced  Terminal  Signals" 


14.7.3.6    CO  Parameters 

CO -structure  1 

co-priority  "normal" 

CO-category  "integer" 

co-size  65535 


14.7.3.7    CO  Values  and  Semantics 

The  values  of  the  CO  are  composite,  with  values  from  table 
below  giving  meaning  to  the  values  in  the  hex  range  00-FF 
when  added  to  them, 

hex  value  meaning 


ICQ  special  key  -  labeled  (see  list) 

200  function  key  depressed 

400  control  key  depressed 

800  shift  key  depressed 

1000  alt  key  depressed 


The  special  key  and  the  function  key  are  mutually  exclusive. 
If  neither  the  function  keys  nor  the  special  keys  are 
pressed,  then  the  value  in  the  hex  range  00-FF  will  be  that 
of  the  normal,  unshifted  code  combination  generated  by  the 
alpha-numeric  key.  Values  in  the  hex  range  00-FF  are  not 
valid  values  for  the  data  element  of  this  Control  Object, 

The  control,  shift,  and  alt  keys  may  appear  in  any 
combination  with  the  special  or  function  keys. 

The  shift  key  must  occur  in  combination  with  at  least  one  of 
the  other  keys  in  the  above  table  to  cause  the  value  to  fall 
outside  the  repertoire  of  the  display  object. 

When  the  special  key  is  depressed,  the  value  of  the  CO 
content  will  be  as  given  in  the  ASN.l  module  below  for  the 
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value  in  the  hex  range  of  00-FF.  Otherwise,  the  value  will 
be  defined  to  be  the  IA5  value  associated  with  the  key. 

STCO  DEFINITIONS   : :=  BEGIN 


Key  : :=  INTEGER  { 


break 

(0). 

bell 

(1), 

backspace 

(2), 

tab 

(3). 

backlab 

(4), 

lineFeed 

(5), 

carRe turn 

(6), 

cancel 

(7), 

substitute 

(8). 

escape 

(9). 

plus 

(10), 

minus 

(11). 

multiply 

(12), 

divide 

(13). 

lef tArrow 

(14). 

rightArrow 

(15), 

up Arrow 

(16), 

downArrow 

(17). 

insert 

(18), 

delete 

(19). 

insertLine 

(20). 

deleteLine 

(21), 

home 

(22). 

end 

(23). 

pageUp 

(24), 

PageDown 

(25). 

pal 

(26), 

pa2 

(27), 

pa3 

(28), 

help 

(29)  , 

statusProcess 

(30), 

interruptProcess 

(31), 

terminateProcess 

(32), 

abortOutput 

(33), 

f ormFeed 

(34), 

clear 

(35), 

print 

(36), 

refresh 

(37), 

systemRequest 

(38), 

endOfRecord 

(39), 

endOfFile 

(40), 

suspendProcess 

(41) 

--  Names  for  combination  keystrokes  are  formed  by  converting  the 

--  initial  letter  to  upper  case  and  prefixing  with  'Ctrl',    'shift'  or 

--  'alt',  which  adds  1024,   2048  or  4096  respectively  to  the  value. 

--  These  prefixes  may  be  used  in  combination  with  one  another  by  a 

--  repetition  of  this  conversion  process,  provided  that  they  appear 

--  from  left  to  right  in  the  order  ' Ctrl',    'shift',    'alt'.  ASN.l 

--  formally  does  not  allow  such  descriptive  additions  but  it  would  be 

--  very  lengthy  to  write  them  all  in  full     --  ) 

END      *(STC0  DEFINITIONS)* 

VTE  profile  definitions  may  refer  to  this  module  for 
convenience  in  describing  semantics. 

14 . 7 . 3 . 8  Additional  Information 
None . 

14.7.3.9  Usa^e 
Defined  in  profile. 


14-11 


June  1990  Stable 

14.7.4       Unsequenced  Terminal  (UT) 

Keyboard  events  may  need  to  be  conveyed  urgently,  out  of  sequence 
with  normal  updates.  This  CO  is  used  to  signal  such  events  from 
the  terminal  to  the  application. 

14.7.4. 1  Entry  Number 

To  be  supplied  by  the  Registration  Authority. 

14.7.4.2  Name  of  Sponsoring  Body 
OSI  Implementors  Workshop  (OIW) ,  VTSIG 

14.7.4.3  Date 

The   date   of   submission  of  this  proposal   is   September  15, 

1989. 

14.7.4.4  Identifier 

oiw-vt-co-misc-ut  OBJECT  IDENTIFIER  : := 
{oiw-vt-co-misc  ut(3)) 

14.7.4.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Unsequenced  Terminal  Signals" 

14.7.4.6  CO  Parameters 

CO- structure  1 

co-priority  "urgent" 

co-category  "integer" 

co-size  65535 

14. 7 .4. 7  CO  Values  and  Semantics 
Same  as  in  ST. 
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14.7.4.8  Additional  Information 
None , 


14.7.4.9  Usage 
Defined  in  profile. 


14.8  OIW  Defined  Profiles 

These  profiles  are  defined  using  the  conventions  specified  in  Annex  A 
of  ISO  9040. 


14.8.1        Telnet  Profile 

OIW  VTE-Profile    Telnet-1988     (rl,  r2) 


14 ■ 8 ■ 1 ■ 1  Introduction 

This  profile  provides  support  for  TELNET- like  operation  for 
users  of  the  ISO  Virtual  Terminal  Service.  It  is  based  on 
the  IS  version  of  ISO  9040  and  ISO  9041. 


14 . 8 . 1 . 2     Association  Requirements 


14. 8 ■ 1 . 2 . 1  Functional  Units 

The  Urgent  Data  Functional  Unit  is  optional,  but  should 
be  used  whenever  available. 

14.8.1.2.2  Mode 

This  is  an  A-mode  profile. 


14.8.1.3     Profile  Body 

Display-objects  =  ^(double  occurrence)* 
I 

{ 

display-object-name  =  D,  *(DISPLAY)* 
do-access  =  "WACA," 

dimensions  =  "two," 
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x-dimension  = 
{ 

X- bound 
x-addresslng 
x-absolute 
x-window 

), 

y-dimension  = 
{ 

y -bound 

y- addressing 

y-absolute 

y-window 

). 

erasure-capability  = 
repertoire-capability  = 
repertoire-assignment  = 
repertoire-assignment  = 


"unbounded, " 
"no  constraint," 
"no,  " 

prof ile- argument- rl 


=  "unbounded," 
=  "higher  only," 
=  "no," 
=  1 

"yes , " 
2, 

prof ile-argument-r2 , 
<ESC>  2/5  2/15  4/2 


{  '    -  ■■  . 

display-object-name  =  K,  *(KEYBOARD)* 
do-.access  =  "WACI ,  " 

dimensions  =  "two," 

x-dimension  = 

( 

x-bound 
X- addressing 
x-absolute 
x-window 


=  "unbounded," 
=  "no  constraint, 


). 

y-dimension  = 
{ 

y -bound 
y-addressing 
y-absolute 
y-window 


=  "no," 

=  prof ile-argument-rl 


=  "unbounded," 
=  "higher  only," 
=  "no," 
=  1 


=  "yes 


erasure -capability 
repertoire-capability  =  2, 

repertoire-assignment  =  prof ile-argument-r2 , 
repertoire-assignment  =  <ESC>  2/5  2/15  4/2 
) 


), 


Control-objects  =  ^(multiple  occurrence)* 
{ 


{  *( SYNCHRONIZE)* 
CO -name 
co-access 
CO-category 


=  SY, 

=  "NSAC," 

=  "symbolic," 
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CO-size  =  1, 

co-priority  =  "urgent" 

}. 

{  *(DISPLAY-SIGNAL)* 

CO -name  =  DI, 

CO- access  =  "WACA," 

co-category  =  "boolean," 

co-size  =  5, 

co-priority  =  "normal," 

CO- trigger  =  "selected" 

). 

{  * (KEYBOARD- SIGNAL)* 

CO-name  =  KB, 

co-access  =  "WACI , " 

CO-category  =  "boolean," 

CO-size  =  5, 

co-priority  =  "normal," 

co-trigger  =  "selected" 

}, 

{  * (NEGOTIATION  BY  INITIATOR)* 

CO -name  =  NI , 

co-access  =  "WACI," 

co-category  =  "boolean," 

co-size  =  4, 

co-priority  =  "normal," 

co-trigger  =  "selected" 

}, 

{  * (NEGOTIATION  BY  ACCEPTOR)* 

co-name  =  NA, 

CO- access  =  "WACA," 

co-category  =  "boolean," 

CO-size  =  4, 

co-priority  =  "normal," 

co-trigger  =  "selected" 

}, 

{  *(GO-AHEAD)* 

CO -name  =  GA, 

co-access  =  "NSAC," 

CO-category  =  "boolean," 

co-size  =  1, 

co-priority  =  "normal," 

CO- trigger  =  "selected" 

} 

), 
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Device-objects  =  *(double  occurrence)* 
{ 

{ 

device-name  =  DI SPLAY- DEVICE , 
device-display-object  =  D, 

device-default-co-initial-value  =  1 . " true , "*( "on" )* 
device -minimum-X- array- length  =  l,*(no  constraint)* 
device -minimum-Y- array- length  =  l,*(no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  NA, 
device-control-object  =  DI , 
device-control-object  =  OA, 

* ( SYNC , NEGOTIATE- ACCEPTOR , DI SPLAY- SIGNAL , 
GO-AHEAD)* 
device-default-co-access  =  "WACA," 
device-default-co-priority  =  "normal" 

*(other   device   object   parameters   assume  corresponding 

DO  values)* 

}, 

{ 

device-name  =  KEYBOARD - DEVICE , 
device-display-object  =  K, 
device-default-co-access  =  "WACI," 
device-default-CO-priority  =  "normal," 
device-default-CO- initial-value  =  1 . " true , "*( "on" )* 
device-minimum-X-array-length  =  l,*(no  constraint)* 
device-minimum-Y-array-length  =  l,*(no  constraint)* 
device-control-object  -  SY, 
device-control-object  =  NI , 
device-control-object  -  KB, 
device-control-object  =  GA, 

* ( SYNC , NEGOTIATE - INITIATOR , KEYBOARD -  SIGNAL , 
GO-AHEAD)* 

*(other   device   object  parameters   assume  corresponding 

DO  values)* 

} 

)  , 

Type  of  delivery  control  =  "simple-delivery-control." 
14.8.1.4    Profile  Arguments 

rl  -  is  used  to  represent  the  line  length  as  the  value  of 
VTE  parameter  x-window  for  both  display  objects.  This 
argtoment  is  mandatory  and  takes  a  nonnegative  integer 
value.  This  argument  is  identified  by  the  identifier 
for  x-window  for  display  object  D. 

r2  -  is  used  to  designate  the  default  repertoire  for  both 
display   objects.       This    argument    is    optional,    if  not 
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present  the  full  US  ASCII  set  is  the  default.  This 
argument  is  identified  by  the  identifier  for  repertoire 
assignment  for  the  display  object  D. 

14 ■ 8 . 1 . 5    Profile  dependent  Control  Object  Information 

This  profile  does  not  reference  any  Control  Objects  which 
are  not  defined  within  this  profile. 

14.8. 1 .6    Profile  Notes 


14.8.1.6.1  Definitive  Notes 

1.  Booleans  in  the  KB  and  DI  control  objects  are  used 
in  this  profile  to  correspond  to  TELNET  commands 
as  follows: 


Control  Object  Boolean  TELNET 


DI/KB  1  IP 

DI/KB  2  AO 

DI/KB  3  AYT 

DI/KB  4  DM 

DI/KB  5  BREAK 


The  equivalent  of  a  TELNET  command  is  achieved  by 
selecting  the  boolean  that  corresponds  to  the 
desired  TELNET  command.  Selecting  a  boolean  in 
the  DI  or  KB  control  object  means  setting  the 
value  of  the  desired  boolean  to  "true."  The  usage 
of  the  mask  element  of  the  boolean  update  is  as 
specified  in  ISO  9041. 

2.  The  equivalent  of  a  TELNET  SYNCH  command  is 
achieved  by  updating  the  SY  control  object  with 
the  single  symbolic  value  of  "SYNCH"  (which  is 
mapped  onto  the  integer  value  1),  and  immediately 
updating  the  DI  (or  KB)  control  object  selecting 
the  DM  boolean.  IP,  AO,  AYT,  or  BREAK  commands 
may  be  accompanied  by  a  SYNCH  command  by  updating 
the  SY  control  object  and  then  updating  the  DI  or 
KB  control  object  selecting  both  the  DM  and  the 
other  desired  boolean.  When  an  update  to  the  SY 
control  object  is  received  subsequent  display 
object  updates  are  discarded  until  an  update  to 
the  DI  or  KB  control  object  is  received  selecting 
the  DM  bit.     If  a  VT-BREAK  is  received  after  an  SY 
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CO  update  has  been  received  and  prior  to  the 
corresponding  DI  or  KB  CO  update  selecting  the  DM 
boolean,  the  discarding  of  updates  is  terminated. 
This  is  necessary  because  the  VT-BREAK  may  have 
caused  the  DI  or  KB  CO  update  to  be  purged. 

The  NI  and  NA  control  objects  are  used  to  emulate 
the  TELNET  option  negotiation  facility.  The 
facility  is  sjnottmetric,  allowing  either  party  to 
open  negotiation  for  a  change  of  mode,  and  every 
negotiation  must  be  accepted  or  rejected  by  the 
opposite  party.  The  rules  for  negotiation  for 
each  of  the  option  controls  are  as  stated  in  RFC 
854  and  as  given  below. 

a.  Only  open  negotiation  for  a  change  from  the 
current  state. 

b.  Only  acknowledge  negotiation  for  a  change 
from  the  current  state. 

c.  Do  not  send  any  object  updates  with  a 
negotiation  outstanding  except  an  update  to 
the  NI  (or  NA)  control  object  to  acknowledge 
negotiation. 

For  full  symmetry,  both  the  NI  and  NA  control 
objects  have  the  same  value  definition  and  consist 
of  4  booleans  with  the  semantics  given  below. 

BIT    Option  Value 

1  Remote  Echo  "false"     Echo    is  local; 

"true"  Echo  is  remote 

2  Suppress  Go  Ahead        "false"      Go  Ahead; 

"true"  Suppress  Go  Ahead 

3  Binary  WACA  "true"  use  binary  WACA; 

"false"  use  default  or 
negotiated  repertoire 
for  WACA  display  object 

4  Binary  WACI  "true"    use    binary   WACI ; 

"false"  use  default  or 
negotiated  repertoire  for 
WACI  display  object 

Booleans  3  and  4  control  the  use  of  the 
Transparent  character  set  for  the  D  and  K  display 
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objects  respectively.  A  value  of  "true"  indicates 
the  use  of  the  binary  repertoire;  "false" 
indicates  the  use  of  the  negotiated  repertoire. 
When  a  party  wants  to  change  a  repertoire 
assignment,  it  must  complete  a  successful  TELNET 
negotiation  to  change  the  option  control.  Then 
the  party  with  the  access  rights  to  the  display 
object  in  question  is  required  to  perform  the 
corresponding  secondary  attribute  modal  update. 

The  TELNET  EC  (erase  character)  command  will  be 
mapped  to  a  pointer  relative  (x:=  x-1)  update  and 
an  erase  current  update.  The  TELNET  EL  (erase 
line)  command  should  will  be  mapped  to  an  erase- 
full-x-array  update  (an  erase  operation  where  the 
extent  is  defined  as  <"start-x, " (Yc ,Xc-l)>  and  a 
pointer  update  to  set  x  =  1.  These  X  dimension 
updates  are  the  only  times  when  backward  explicit 
addressing  is  permitted. 

The  X  address  of  the  pointer  can  be  moved  forward 
only  by  implicit  pointer  addressing.  Addressing 
of  the  Y  dimension  is  limited  to  the  next  X- array 
update  operation. 

The  VT  next  X- array  update  operation  will  be  sent 
in  place  of  the  TELNET  NVT  "CR.LF"  sequence. 

While  the  "binary"  repertoire  is  being  used  no 
mapping  to  pointer  addressing  or  erase  operations 
will  be  done. 

The  repertoire  designation  "7-bit  ASCII  (GO+CO)" 
refers  to  the  repertoire  invoked  by  ISO  2022 
defined  character  set  designating  escape  sequences 
<ESC>  2/8  4/2,  "void,"  <ESC>  2/1  4/0.  The 
repertoire  designation  "7-bit  ASCII  (GO  only)" 
refers  to  the  repertoire  invoked  by  the  ISO  2022 
defined  character  set  designating  escape  sequence 
<ESC>  2/8  4/2.  The  designation  "binary"  refers  to 
the  "Virtual  Terminal  Service  Transparent  Set" 
registered  in  the  International  Register  under  ISO 
2375  register  value  125  and  invoked  by  the  escape 
sequence  <ESC>  2/5  2/15  4/2. 

No  termination  event  list  is  specified  so  that 
data  buffering  and  delivery  can  be  controlled 
according  to  context.  If  local  echoing  is 
enabled,  the  local  newline  or  enter  event  shall 
trigger  a  VT-DELIVER  request.     With  remote  echo  a 
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timeout  or  buffer  length  may  be  used  to  trigger  a 
VT-DELIVER  request.     This  buffer  length  may  be  1. 


14.8.1.6.2 


Informative  Notes 


1.  Users  of  this  profile  should  refer  to  the  TELNET 
specification  (MIL-STD-1782)  and  RFCs  854  and  855 
for  semantics  of  the  TELNET  commands.  These 
documents  can  be  obtained  by  contacting  SRI 
International,  DDN  Network  Information  Center,  333 
Ravenswood  Ave.,  Menlo  Park,  CA  94025,  (415)  859- 
3695. 

2.  An  update  to  the  GA  control  object  is  equivalent 
to  the  TELNET  Go  Ahead  command. 

3.  If  the  "go  ahead"  facility  has  been  negotiated 
then  following  a  VT-BREAK,  only  the  association 
acceptor  has  the  right  to  send  data.  In  the  event 
of  VT-BREAK  the  echo  control  objects  are 
reinitialized  to  "false,"  meaning  local  echo.  If 
remote  echo  is  desired  it  must  be  re-negotiated 
following  VT-BREAK. 

4.  Negotiation  of  TELNET  options  other  than  echo, 
transmit  binary,  and  SUPPRESS  GO  AHEAD  is  not 
supported  by  this  profile.  Negotiations  for  these 
three  options  can  take  place  at  any  time  during  a 
session. 


14. 8 . 1 . 7    Specific  Conformance  Requirements 
The  following  character  sets  are  required: 

o        The  GO  character  set  for  U.S.   7 -bit  ASCII   (values  32- 


126), 


o 


The  full  U.S.  7-bit  ASCII  (values  0-127).  and 


o 


The  transparent  character  set,  see  Definitive  Note  8  in 
section  14.8.1.6.1. 


14.8.2 


Transparent  Profile 
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OIW  VTE-Profile    Transparent- 1988  (rl) 
14. 8 ■ 2 ■ 1  Introduction 

This  profile  is  intended  to  provide  a  transparent  mode  of 
operation  which  allows  VT-users  to  exchange  transparently 
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uninterpreted  sequences  of  characters  but  with  the  added 
benefit  of  delivery  control  to  enable  the  VT-users  to 
determine  when  the  character  sequences  are  to  be  delivered. 
This  profile  may  be  used  when  VT-users  wish  to  control 
terminals  directly  through  the  use  of  embedded  control 
characters . 


14.8.2.2    Association  Requirements 


14.8.2.2.1  Functional  Units 

No  additional  functional  units  are  required  by  this 
profile . 


14.8.2.2.2  Mode 

This  is  an  A-mode  profile. 


14.8.2.3    Profile  Body 

Display-objects  *(double  occurrence)*  = 
{ 

{ 

display -object -name  =  Dl , 
do-access  =  "WACA," 

dimensions  =  "one," 

X- dimensions  = 

( 

x-addressing  =  "not-permitted" 

). 

repertoire-assignment  =  prof ile -argument- rl 

}, 

{ 

display-object-name  =  D2 , 
do-access  =  "WACI , " 

dimensions  =  "one," 

X- dimension  = 

{ 

x-addressing  =  "not-permitted" 

). 

repertoire-assignment  =  prof ile -argument- rl 
) 

). 

type-of -delivery-control  =  "simple-delivery-control." 
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14.8.2.4  Profile  Arguments 

rl  -  is  optional  and  enables  negotiation  of  a  value  for 
the  VTE-parameter  repertoire-assignment  for  the  two 
display  objects  (which  always  have  the  same  value  of 
repertoire  assignment  when  the  profile  is  called) .  The 
default  value  of  this  argument  is  the  "Virtual  Terminal 
Transparent  Set"  registered  in  the  International 
Register  under  ISO  2375  register  value  125,  invoked  by 
the  escape  sequence  <ESC>  2/5  2/15  4/2.  This  argument 
is  identified  by  the  identifier  for  repertoire- 
assignment  for  display  object  Dl . 

14. 8 . 2 . 5  Profile  dependent  Control  Object  Information 
This  profile  does  not  reference  any  Control  Objects. 

14.8.2.6  Profile  Notes 

1.  This  profile  is  intended  primarily  for  applications 
requiring  a  simultaneous  two  way  exchange  of  sequences 
of  uninterpreted  characters.  The  semantics  usually 
associated  with  the  display  object  are  not  used;  for 
the  purposes  of  this  profile,  the  primary  attributes  of 
the  character-box  graphic  elements  are  actually  octets 
which  are  passed  directly  to  the  real  device.  There  is 
no  relationship  between  the  elements  of  the  X-array  and 
the  character  boxes  of  the  real  device;  the  secondary 
attributes  of  the  display  object  are  not  utilized.  The 
only  operation  on  the  display  object  which  must  be 
supported  is  the  text  operation.  An  alternative 
repertoire  may  be  selected. 

14.8.2.7  Specific  Conformance  Requirements 

Support  for  the  default  (transparent)  character  set  is 
required.  It  is  strongly  recommended  that  the  profile 
argiament  not  be  used. 

14.8.3        Forms  Profile 

OIW  VTE-Profile  Forms-1989     (rl,r2,   .    .   .  r28) 
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14.8.3.1  Introduction 

This  S-mode  VTE-profile  is  intended  for  supporting  the  use 
of  forms  based,  field  oriented  data  entry  applications 
between  a  terminal  and  a  host  system. 

It  provides  facilities  for: 

defining  and  using  screen  forms, 

defining  field  validation  and  field  entry  rules,  and 

controlling  and  validating  field  entry. 

This  VTE-profile  includes  support  of  an  optional  terminal- 
end  locally  attached  printer. 

14.8.3.2  Association  Requirements 

14.8.3.2.1  Functional  Units 

The  following  VT  functional  units  are  required  for 
operation  with  this  profile: 

Enhanced  access-rules, 

Structured  COs , 

Fields,  and 

Reference  Information  Objects 

The  following  VT  functional  units  are  optional  for 
operation  with  this  profile: 

Urgent  Data 

14.8.3.2.2  Mode 

This  is  an  S-mode  profile. 


14-23 


June  1990  Stable 


14.8.3.3    Profile  Body 

Display-objects  *(single  occurrence)*  = 
{ 

display-object-name  =  A, 
DO-access  =  "WAVAR," 

dimensions  =  "three," 

X- dimension  = 
( 

x-bound  =  prof ile-argument-rl , 

x-addressing      =  "no  constraint," 
x-absolute         =  "yes," 
x-window  =  x-bound 

). 

y- dimension  = 
( 

y-bound  =  prof ile- argument -r2 , 

y-addressing      =  "no  constraint," 
y-absolute         =  "yes," 
y-window  =  y-bound 

). 

z- dimension  = 
{ 

z -bound  =  "unbounded," 

z-addressing      =  "no  constraint," 

z-absolute         =  "no," 

z-window  =  prof ile-argument-r3 

}. 

erasure-capability  =  "yes," 

repertoire-capability  *( implicitly  defined  by  r4)*, 
repertoire-assignment  =  prof ile -argument -r4 , 

font-capability    *(implicitly  defined  by  r5)*, 
font -assignment  =  prof  ile- argtiment-r5 , 

DO-emphasis  =  prof ile -argument -r6 , 

foreground-colour-capability  =  prof ile-argument-r7 , 
foreground-colour-assignment  =  prof ile-argument-r8 , 
background-colour-capability  =  prof ile-argument-r7 , 
background-colour-assignment  =  prof ile-argument-r9 , 

block-definition-capability  =  "no," 
field-definition-capability  =  "yes," 
max-fields  =  "unbounded," 

max-f ield-elements  =  prof ile-argument-rlO , 
access-outside-f ields  =  prof ile-argument-rll 
). 
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Control-objects  = 
( 

{  *(Field  Definition  CO)* 

CO -name  =  FD, 

CO- type -identifier  =  vt-b-sco-fdco , 

CO-structure  =  "non-parametric," 

co-access  =  "WAVAR"  +  prof ile-argument-rl2 , 

CO-priority  =  "normal," 

CO-trigger  =  "not-selected" 

), 


{  *(Field  Entry  Instructions  CO)* 

CO -name 

=  EI, 

CO- type -  identifier 

=  "mandatory- feico , " 

CO-structure 

=  "non-parametric , " 

CO-access 

=  "WAVAR"  +  profile-argument-rl2. 

CO-priority 

=  "normal , " 

CO-trigger 

=  "not-selected" 

{  *(Field  Entry  Pilot  CO)* 

CO -name  =  EP, 

CO-type-identif ier  =  "mandatory- fepco , " 

CO-structure  =  "non-parametric," 

CO-access  =  "WAVAR"  +  prof ile-argument-rl2 , 

CO-priority  =  "normal," 

CO-trigger  =  "not-selected" 

), 


{  *(Context  CO)* 
CO -name 

CO- type- identifier 

CO -s true ture 

CO-access 

CO-priority 

CO-trigger 

}, 


=  CC, 

=  vt-b-sco-cco , 
=  6, 

=  "WAVAR," 

=  "normal," 

=  "not-selected" 


{  *(Transmission  Policy  CO)* 


CO -name 

CO- type- identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

co-size 


TP, 

vt-b-sco- tpco , 
1. 

"WAVAR"  +  profile-argument-rl2, 

"normal , " 

"not-selected, " 

"boolean, " 

4 
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{  *(Multiple  occurrence  of  optional  COs.  All 
unspecified  VTE- parameters  of  such  COs  are  determined 
by  their  CO- type-identifier  through  their  registered 
definition.  They  may  include  parameters  specified  to 
be  additional  profile  arguments,  which  should  follow 
the  appropriate  CO- type -identifier  argument  value)* 

co-name  =  prof  ile-argximent-rl3 , 

co-type- identifier    =  prof ile-argument-rl4 
). 


{  *(Form  Waiting  Time  CO)* 


CO -name 

CO- type- identifier 

CO- structure 

CO-access 

co-priority 

CO- trigger 

CO-category 

CO-size 

), 


WT, 

"waiting- time, " 
1. 

"WAVAR, " 
"normal , " 
"not-selected, " 
" integer, " 
65535 


*(The   initial  value   for  WT   is   zero,    implying  that  a  Fora 

Waiting  Time  is  not  to  be  used.)* 

*(The  following  four  COs,  (SA,  UA,  ST,  and  UT) ,  are 
registered    with    the    OIW    registration    authority    and  are 

referenced  by  this  profile.)* 

{  *(As  defined  in  14.7.1  of  this  document)* 

CO-name  =  SA, 
CO-type-identif ier    =  oiw-vt-co-misc-sa, 

co-structure  =  1, 

co-access  =  "WAVAR"  +  prof ile-argument-rl2 , 

co-priority  =  "normal," 

co-trigger  =  "not-selected," 

co-category  =  "symbolic," 

co-size  =  11 
), 


{  *(As  defined  in  14. 

CO-name  = 

CO- type- identifier  = 

CO -structure  = 

CO-access  = 

CO-priority  = 

CO- trigger  = 

CO-category  = 
co-size 
}. 


7.2  of  this  document)* 
UA, 

oiw-vt-co-misc-ua, 
1, 

profile-argument-rl2, 
"urgent, " 
"not-selected, " 
"symbolic , " 
11 
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{  *(As  defined  in  14.7.3  of  this  document)* 


CO -name 

co-type- identifier 
CO- structure 
CO-access 

co-priority 
CO- trigger 
co-category 
CO-size 
). 


=  ST, 

=  oiw-vt-co-misc-st , 
=  1. 

=  "WAVAR"  +  opposite  of 

prof ile-argument-rl2 , 

=  "normal , " 

=  "not-selected," 

=  "integer," 

=  65535 


(  *(As  defined  in  14.7.4  of  this  document)* 


CO -name 

CO- type -  identifier 

CO- structure 

CO-access 

co-priority 

co-trigger 

CO-category 

co-size 

} 


=  UT, 

=  oiw-vt-co-misc-ut , 
=  1. 

=  opposite  of  prof ile-argument-rl2 , 

=  "urgent," 

=  "not-selected," 

=  "integer," 

=  65535 


Device -objects    *(single  or  double  occurrence)*  = 
( 

{ 

device -name  =  D, 

device-default-co-access  =  "WAVAR," 
device-default-CO-priority  =  "normal," 
device-default-co-trigger  =  "not-selected," 
device-default-CO- initial-value  =  l."true," 
device-repertoire-assignment  =  prof ile-argument-rl5 , 
device-font-assignment  =  prof ile-argument-rl6 , 
device -emphasis  =  prof ile-argument-rl7 , 
device -foreground- CO lour- assignment  = 

prof  ile-argximent-rl8 , 
device -background- CO lour -assignment  = 

prof ile-argument-rl9 , 
device-minimum-X-array- length  =  prof ile-argument-r20 , 
device -minimum-Y- array- length  =  prof ile -argument- r21 , 


device 

-control- 

object 

FD, 

device 

-control- 

object 

CC, 

device 

-control- 

obj  ect 

SA, 

device 

-control- 

object 

UA, 

device 

-control- 

obj  ect 

ST, 

device 

-control- 

object 

UT, 

device 

- control - 

obj  ect 

WT, 

device 

-control- 

object 

TP, 
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device-control-object  =  prof ile-argument-r22 , 

device-display-object  =  A 

), 

IF  r23  =  "true"  THEN      *(define  printer)* 
{ 

device -name  =  P, 

device -default-co-access  =  "NSAC," 
device-default-co-priority  =  "high," 
device-default-co-trigger  =  "not-selected," 
device-default-CO- initial-value  =  1. "false," 
device-repertoire-assignment  =  prof ile- argument -r 24 , 
device-font-assignment  =  prof ile-argument-r25 , 
device -emphasis  =  prof ile-argument-r26 , 
device- foreground-colour-assignment  = 

prof ile-argument-r27 , 
device-background-colour-assignment  = 

prof ile-argument-r28 , 
device -minimum-X- array- length  =  prof ile-argument-r29 , 
device -minimum-Y- array- length  =  prof ile-argument-r30 , 
device-control-object  =  FD, 
device-control-object  =  SA, 
device-control-object  =  UA, 

device-control-object  =  prof ile-argument-r31 , 

device-display-object  =  A 

) 

}, 

type -of- delivery- control  =  "simple  delivery  control." 

FIXED  Field  Entry  Instruction  Definitions  -  non-parametric 

Optional  Field 

field  entry  is  optional.  This  FEI  is  provided  for 
completeness  only,  as  a  field  not  linked  to  one  of  the 
Mandatory  field.  Selectable  field  or  Protected  field  FEIs  is 
necessarily  optional.     This  FEI  can  never  be  violated. 

Mandatory  Field 

-  field  entry  is  mandatory.  Violation  of  this  FEI  will 
occur  if  all  array  elements  of  this  field  are  empty  when  one 
of  the  reactions  FEROl  (Transmit  updates)  or  FER02 
(Relinquish  WAVAR)  is  initiated.  See  also  the  specification 
of  these  reactions  given  below. 

Protected  Field 

-  the  field  is  protected  from  field  entry.  Violation  of 
this    FEI    will    occur    if   an   attempt   is   made    to   change  the 
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primary  or  secondary  attribute  of  any  array  element  of  this 
field. 

Fill  Field 

-  all  array  elements  k=l  through  k=last  must  have  a  primary 
attribute.  Violation  of  this  FEI  will  occur  if  any  array 
element  of  this  field  is  empty  when  one  of  the  reactions 
FEROl  (Transmit  updates)  or  FER02  (Relinquish  WAVAR)  is 
initiated.  See  also  the  specification  of  these  reactions 
given  below. 

Echo  Received  Character 

allowed  field  entry  characters  are  to  be  echoed  as 
received.  This  FEI  is  provided  for  completeness  only,  as  by 
default  characters  will  be  echoed  as  received  unless  the 
field  is  linked  to  either  the  Echo  Off  or  the  Echo  Specified 
Character  FEI.     This  FEI  can  never  be  violated. 

Echo  Off 

-  received  field  entry  characters  should  not  be  echoed. 
This  FEI  can  never  be  violated. 

Ignore  Case 

-  if  this  FEI  is  linked  to  a  field,  upper  and  lower  case 
alphabetic  characters  should  be  considered  as  equivalent 
during  the  validation  of  field  input  against  all  other  FEIs 
linked  to  the  same  field.  This  affects  the  interpretation 
of  the  Allowed  First  Characters,  Allowed  Characters, 
Disallowed  Characters  and  Allowed  String  Values  FEIs, 
including  the  precedence  rules  between  the  first  three  of 
these  FEIs.     This  FEI  can  never  be  violated. 

Inhibit  Logical  Rendition  Attribute  Operation 

-  no  form  of  logical  attribute  operation,  with  the  exception 
of  character  repertoire  switching  as  given  below,  can  be 
performed  on  the  field.  Character  repertoire  changes  are 
permitted  if  also  permitted  by  Allowed  First  Characters  or 
Allowed  Characters,  see  below.  This  FEI  is  intended  to  be 
used  when  the  rendition  secondary  attributes  are  to  be  kept 
under  "application"  control.  See,  for  example,  Allowed 
First  Characters  for  a  case  of  reference  to  the  field  modal 
values . 


DYNAMIC  Field  Entry  Instruction  Definitions  -  parametric 

Selectable  field 

-  the  field  is  selectable,  i.e.,  field  entry  is  not 
permitted  but  information  is  conveyed  by  the  selection  of 
one  such  field  from  a  number  of  alternatives. 
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The  manner  in  which  the  field  that  is  the  current  candidate 
for  selection  is  displayed  on  the  real  device  is  determined 
by  the  optional  "visit"  parameter  of  this  FEI .  This 
parameter  specifies  the  secondary  attributes  to  be  used  for 
showing  or  highlighting  this  candidate  to  the  user.  If  it 
is  omitted,  an  implementation- dependent  default  is  used. 

The  manner  in  which  the  field  that  is  actually  selected  is 
displayed  on  the  real  device  is  determined  by  the  optional 
"select"  parameter  of  this  FEI.  This  parameter  specifies 
the  secondary  attributes  to  be  used  for  showing  or 
highlighting  the  selected  field  to  the  user.  If  it  is 
omitted,  an  implementation-dependent  default  is  used. 

The  mechanisms  for  moving  among  candidates  and  for  actually 
selecting  the  current  candidate  are  implementation  defined. 
Typically,  a  selectable  field  will  be  considered  as  a 
candidate  for  selection  when  the  cursor  is  placed  on  a 
character  within  the  selectable  field.  Actual  selection 
generates  the  Field  Selected  FEE.  A  selected  field  is 
indicated  in  a  delivered  update  by  an  addressing  operation 
setting  k=l  and  f  and  z  to  indicate  the  selected  field. 
These  values  will  be  reported  to  the  host  in  the  CCO  if 
WAVAR  is  relinquished  in  reaction  to  this  FEE.  Violation  of 
this  FEI  will  occur  if  an  attempt  is  made  to  change  the 
primary  or  secondary  attribute  of  any  array  element  of  this 
field. 

Echo  Specified  Character 

-  specifies  the  character  which  is  to  be  echoed  to  the  user 
in  response  to  each  allowed  character  entered  into  the 
field.  The  secondary  attributes  of  the  echoed  character  may 
be  specified.  Any  secondary  attribute  that  is  not  given  an 
explicit  value  in  the  FEI  takes  a  default  value  in 
accordance  with  Definitive  Note  4.  This  FEI  can  never  be 
violated. 

Minimum  Entry 

-  all  array  elements  k=l  through  k=Minimum  Entry  must  have  a 
primary  attribute.  If  Minimum  Entry  exceeds  field  size, 
then  all  positions  in  the  field  must  be  filled.  Violation 
of  this  FEI  will  occur  if  any  of  the  specified  array 
elements  are  empty  when  one  of  the  reactions  FEROl  (Transmit 
updates)  or  FER02  (Relinquish  WAVAR)  is  initiated.  See  also 
the  specification  of  these  reactions  given  below.  When  a 
field  is  associated  with  both  the  Optional  Field  FEI  and  a 
Minimum  Entry  FEI,  the  field  is  optional  but  if  entry  is 
elected,  the  number  of  characters  specified  by  the  Minimum 
Entry  FEI  must  then  be  entered. 
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Allowed  First  Characters 

specifies  a  set  of  allowed  characters  for  the  first 
character  position  of  the  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be 
checked;  see  Definitive  Note  3. 

Allowed  Characters 

-  specifies  a  set  of  allowed  characters  for  all  character 
positions  within  the  field.  Either  primary  attributes  alone 
or  both  primary  and  secondary  attributes  may  be  checked;  see 
Definitive  Note  3.  If  Allowed  First  Characters  and  Allowed 
Characters  are  both  specified  for  a  particular  field,  then 
the  set  of  Allowed  First  Characters  applies  to  the  first 
character  position  of  the  field  and  the  set  of  Allowed 
Characters  applies  to  the  second  through  last  character 
positions  of  the  field. 

Disallowed  Characters 

-  specifies  a  set  of  disallowed  characters  for  all  character 
positions  within  a  field.  Either  primary  attributes  alone 
or  both  primary  and  secondary  attributes  may  be  checked;  see 
Definitive  Note  3.  If  Allowed  First  Characters  and 
Disallowed  Characters  are  both  specified  for  a  particular 
field,  then  the  set  of  Allowed  First  Characters  applies  to 
the  first  character  position  of  the  field  and  the  set  of 
Disallowed  Characters  applies  to  the  second  through  last 
character  positions  of  the  field.  When  a  field  is 
associated  with  Allowed  Characters  FEI(s)  and  Disallowed 
Characters  FEI(s)  that  have  characters  in  common,  the  common 
characters  are  considered  as  disallowed. 

Entry  Invoke  Character 

specifies  the  attributes  to  be  used  for  showing  or 
highlighting  to  the  user  where  the  next  character  entry  is 
to  be  made.  Both  primary  and  secondary  attributes,  or 
secondary  attributes  alone,  may  be  specified  to  over-ride 
the  corresponding  values  present  in  the  array  element 
concerned.  Any  secondary  attribute  that  is  not  given  an 
explicit  value  in  the  FEI  takes  a  default  value  in 
accordance  with  Definitive  Note  4.  Fields  that  are  not 
linked  to  an  Entry  Invoke  Character  FEI,  utilize  a  device 
dependent  entry  invoke  character  which  may  or  may  not  be 
represented  in  the  character  repertoire  negotiated  for  the 
device.  This  FEI  can  never  be  violated. 

Waiting  Time 

-  specifies  the  number  of  seconds  to  wait  for  field  entry  to 
complete  after  the  cursor  has  been  positioned  within  the 
field.  Fields  that  are  not  associated  with  a  Waiting  Time 
FEI    are   not    subject    to    the    "Field  Waiting  Time  Expired" 
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Field  Entry  Event.  Note  that  an  overall  waiting  time  for  an 
entire  form  may  be  set  by  use  of  the  "waiting-time"  control 
object  defined  in  Definitive  Note  1.  This  FEI  can  never  be 
violated. 

Allowed  String  Values 

-  specifies  a  list  of  strings  which  identify  valid  field 
values.  The  strings  are  specified  as  either  a  discrete 
OCTET  STRING  or  a  range  of  OCTET  STRING,  or  combination  of 
both. 

Ranges  are  specified  using  a  lower  "value"  OCTET  STRING  and 
a  higher  "value"  OCTET  STRING.  The  "value"  of  an  OCTET 
STRING  is  the  integer  value  derived  from  the  collating 
sequence  corresponding  to  the  repertoire  explicitly  or 
implicitly  specified  for  the  OCTET  STRING.  For  example,  the 
ISO  646  string  'AB'  has  the  integer  value  4142(16)  and  the 
string  'ABC  has  the  value  414243(16). 

When  strings  of  unequal  length  are  compared,  the  smaller 
string  is  filled  on  the  right  with  enough  spaces  to  make  the 
strings  of  equal  length.  The  comparison  of  ISO  646  strings 
'AB'  and  'ABC  would  be  accomplished  by  first  converting  the 
string  'AB'  to  'AB'  thus  creating  the  value  414220(16)  to  be 
compared  against  the  value  414243(16).  The  value  of  the 
space  character  is  derived  from  the  collating  sequence 
corresponding  to  the  repertoire  identified  in  the  field 
modal  attributes.  If  this  repertoire  does  not  contain  a 
space,  then  the  value  20(16)  is  used. 

Either  primary  attributes  alone  or  both  primary  and 
secondary  attributes  may  be  checked;  see  Definitive  Note  3. 
A  single  set  of  secondary  attribute  values  may  be  specified 
for  each  individual  OCTET  STRING  or  range  of  OCTET  STRINGS. 

Allowed  Numeric  Values 

-  specifies  a  list  of  numeric  strings  which  identify  valid 
field  values.  The  strings  are  specified  as  either  a 
discrete  OCTET  STRING  or  a  range  of  OCTET  STRING,  or  a 
combination  of  both. 

Ranges  are  specified  using  a  lower  "value"  OCTET  STRING  and 
a  higher  "value"  OCTET  STRING.  The  "value"  of  an  OCTET 
STRING  is  the  integer  value  derived  from  the  collating 
sequence  corresponding  to  the  repertoire  explicitly  or 
implicitly  specified  for  the  OCTET  STRING.  For  example,  the 
ISO  646  string  '12'  has  the  integer  value  3132(16)  and  the 
string  '123'  has  the  integer  value  313233(16). 
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When  strings  of  unequal  length  are  compared,  the  smaller 
string  is  filled  on  the  left  with  enough  zero  characters  to 
make  the  strings  of  equal  length.  The  comparison  of  ISO  646 
strings  '12'  and  '123'  would  be  accomplished  by  first 
converting  the  string  '12'  to  '012'  thus  creating  the  value 
303132(16)  to  be  compared  against  the  value  313233(16).  The 
value  of  the  zero  character  is  derived  from  the  collating 
sequence  corresponding  to  the  repertoire  identified  in  the 
field  modal  attributes.  If  this  repertoire  does  not  contain 
a  zero,  then  the  value  30(16)  is  used. 

Either  primary  attributes  alone  or  both  primary  and 
secondary  attributes  may  be  checked;  see  Definitive  Note  3. 
A  single  set  of  secondary  attribute  values  may  be  specified 
for  each  individual  OCTET  STRING  or  range  of  OCTET  STRINGS. 

Mutually  Exclusive  FEIs 

Some  FEIs  specify  field  entry  validation  rules  that  are  in 
conflict  with  the  rules  specified  by  other  FEIs.  For 
example,  a  particular  field  cannot  be  both  "protected"  and 
"mandatory."  Such  conflicting  FEIs  cannot  be  associated 
with  the  same  field.  The  following  table  defines  the  sets 
of  conflicting  FEIs. 
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Table  14.1. 

FEI 

Optional  Field 
Mandatory  Field 
Selectable  Field 
Protected  Field 
Fill  Field 


Echo  Received 
Character 


Echo  Off 


Ignore  Case 

Inhibit  Logical 
Rendition  Attribute 
Operation 

Echo  Specified 
Character 

Minimum  Entry 

Allowed  First 
Characters 

Allowed 
Characters 

Disallowed 
Characters 

Entry  Invoke 
Character 


Sets  of  conflicting  FEIs 
Conflicting  FEIs 

Mandatory  Field,  Selectable  Field,  Protected  Field. 
Optional  Field,  Selectable  Field,  Protected  Field. 
All  except  Entry  Invoke  Character  and  Waiting  Time. 
All. 

Selectable  Field,  Protected  Field,  Allowed  String  Values 
Allowed  Numeric  Values. 

Selectable  Field,  Protected  Field,  Echo  Off, 
Echo  Specified  Character. 

Selectable  Field,  Protected  Field, 

Echo  Received  Character,  Echo  Specified  Character. 

Selectable  Field,  Protected  Field. 

Selectable  Field,  Protected  Field. 


Selectable  Field,  Protected  Field,  Echo  Off, 
Echo  Received  Character  i 

Selectable  Field,  Protected  Field. 

Selectable  Field,  Protected  Field, 

Allowed  String  Values,  Allowed  Numeric  Values. 

Selectable  Field,  Protected  Field, 

Allowed  String  Values,  Allowed  Numeric  Values. 

Selectable  Field,  Protected  Field, 

Allowed  String  Values,  Allowed  Numeric  Values, 

Protected  Field. 


Waiting  Time 

Allowed  String 
Values 


Protected  Field. 

Selectable  Field,  Protected  Field, 

Fill  Field,  Allowed  First  Characters,  Allowed  Characters 
Disallowed  Characters,  Allowed  Numeric  Values. 
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Allowed  Numeric  Selectable  Field,  Protected  Field, 

Values  Fill    Field,    Allowed    First    Characters,    Allowed  Characters, 

Disallowed  Characters,  Allowed  String  Values. 

FEICO  Update  Syntax 

In  the  following  syntax,  ASN.l  Value  Assignments  have  been 
used  to  attach  value  references  to  values  of  type  NULL. 
This  enables  the  values  to  be  referenced  by  these  names 
alone,  without  the  need  to  follow  the  identifier  explicitly 
with  the  value  NULL. 


FEI  DEFINITIONS  : :=  BEGIN 


FEI  : :=  CHOICE  { 

feiO  [0] 

feil  [1] 

fei2  [2] 

fei3  [3] 

fei4  [4] 

fei5  [5] 

fei6  [6] 

fei7  [7] 

selectableField  [8] 
visit          [0]  IMPLICIT  S 
select        [1]  IMPLICIT  S 

echoSpecif iedCharacter  [9] 

minimumEntries  [10] 

allowedFirstCharacters  [11] 

allowedCharacters  [12] 

disallowedCharacters  [13] 

entrylnvokeCharacter  [14] 


[0]  IMPLICIT 
[ 1 ]  IMPLICIT 
waitingTime  [15' 
allowedStringValues  [16^ 
allowedNumeric Values  [17] 


IMPLICIT  NULL, 

IMPLICIT  NULL, 

IMPLICIT  NULL, 

IMPLICIT  NULL, 

IMPLICIT  NULL, 

IMPLICIT  NULL, 

IMPLICIT  NULL, 

IMPLICIT  NULL, 

IMPLICIT  SEQUENCE  { 
ecAttributes  OPTIONAL, 
ecAttributes  OPTIONAL  ) , 

IMPLICIT  Character, 

IMPLICIT  INTEGER, 

IMPLICIT  CharacterValues , 

IMPLICIT  CharacterValues, 

IMPLICIT  CharacterValues, 

CHOICE  { 
Character , 
SecAttributes  ) , 

IMPLICIT  INTEGER, 

IMPLICIT  CharacterValues, 

IMPLICIT  CharacterValues  ) 


optionalField  FEI 

mandatoryField  FEI 

protectedField  FEI 

fillField  FEI 

echoReceivedChar  FEI 

echoOff  FEI 

ignoreCase  FEI 

inhibitLogRendAttOp  FEI 


feiO 
feil 
fei2 
feiS 
fei4 
fei5 
fei6 
fei7 


NULL 
NULL 
NULL 
NULL 
NULL 
NULL 
NULL 
NULL 


Character  : :=  SEQUENCE  { 

primaryValue       [0]     IMPLICIT  PriValue, 
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attributes  [1]     IMPLICIT  SecAttributes  OPTIONAL  } 

--  When  used  as  one  element  of  a  comparison,  secondary 
--  attributes  are  to  be  compared  only  if  the  attributes 
--  element  is  present. 

CharacterValues  : :=  SEQUENCE  OF  SEQUENCE  { 

lowValue  [0]     IMPLICIT  Character, 

highValue  [1]     IMPLICIT  PriValue  OPTIONAL  } 

--  The  default  for  highValue  is  the  associated 
--  lowValue.     Octet  values  specified  for  highValue 
--  are  constrained  by  the  repertoire  corresponding 
--  to  the  lowValue  value.     The  relationship 
--   [lowValue  <=  highValue]  must  be  true. 

PriValue  : :=  OCTET  STRING 

--  The  octet  string  comprising  a  value  of  the  PriValue 
--  type  is  constrained  to  the  encoding  of  a  sequence 
--of  characters  from  the  repertoires  negotiated  for 
--  the  associated  Display  Object.     When  used  in  the 
--  ASN.l  module  FEI ,   the  octet  string  is  restricted  to 
--  the  encoding  of  a  single  character  except  for  its 
--  use  in  allowedStringValues  and  allowedNumeric- 
--  Values. 

SecAttributes  : :=  SEQUENCE  { 


repertoire 

[0] 

IMPLICIT 

INTEGER  OPTIONAL, 

foregroundColour 

[1] 

IMPLICIT 

INTEGER  OPTIONAL, 

backgroundColour 

[2] 

IMPLICIT 

INTEGER  OPTIONAL, 

emphasis 

[3] 

IMPLICIT 

PrintableString 

OPTIONAL, 

font 

[4] 

IMPLICIT 

INTEGER  OPTIONAL  ) 

END  *(FEI  DEFINITIONS)* 

FEICO  "mandatory- feico"  Initial  Content 

For  each  FEIRxx,  xx  identifies  the  integer  value  to  be  used 
as  "feirList  recordlndex"  in  FDCOUpdate  operations. 
FEICOUpdate  operations  must  use  an  "index"  greater  than  127. 
Note  that  the  character  oriented  FEIRs  for  the  initial  FEICO 
utilize  the  default  secondary  attributes,  and  that  the 
Selectable  Field  FEI  uses  implementation- dependent  defaults 
for  the  'visit'  and  'select'  secondary  attributes.  The  FEIR 
contents  are  specified  in  terms  of  ASN.l  Value  Notation 
appropriate  to  the  FEICO  Update  Syntax  specified  above. 

FEIROO        --  Not  used  -- 

FEIROl  optionalField 
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FEIR02  mandatoryField 

FEIR03  selectableFleld  {  } 

FEIR04  protectedField 

FEIR05  fillFleld 

FEIR06  echoReceivedChar 

FEIR07  echoOff 

FEIR08  IgnoreCase 

FEIR09  InhibitLogRendAttOp 

FEIRIO  allowedCharacters  {{  lowValue  {'41'H}, 
highValue  '5A'H  ))  --  A,B,...,Z  -- 

FEIRll        allowedCharacters  {{   lowValue  {'61'H), 
highValue  '7A'H  })  --  a,b,...,z  -- 

FEIR12        allowedCharacters  {{  lowValue  {'30'H}, 
highValue  '39'H  ))  --  0,1,..., 9  -- 

FEIR13        disallowedCharacters  {{   lowValue  {'41'H), 
highValue  '5A'H  ))   --  A,B,...,Z  -- 

FEIR14        disallowedCharacters  {{  lowValue  {'61'H}, 
highValue  '7A'H  ))  --  a,b,...,z  -- 

FEIR15        disallowedCharacters  {{  lowValue  {'30'H), 
highValue  '39'H  }}  --  0,1  9  -- 

FEIR16-FEIR127  --  These  values  are  reserved  -- 

Field  Entry  Event  Definitions 

The  Field  Entry  Events  for  the  mandatory  FEPCO  are  listed 
below.  A  parameter  of  type  "Range"  is  a  sequence  of  integer 
pairs,  each  with  an  optional  bitmask.  Each  pair  gives  the 
end  points  of  an  interval  of  integer  values.  An  integer 
value  lies  within  the  range  specified  if,  after  applying  the 
bitmask  (if  given)  to  its  binary  form,  it  lies  in  any  of 
these  intervals.  The  end  points  of  an  interval  are  included 
in  the  values  of  that  interval. 

It  is  permissible  for  the  ranges  specified  by  the  FEEs 
referenced  in  the  entry  control  FEPR-list  of  a  field  to 
overlap.     When  an  event  occurs  which  is  referenced  in  this 
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way  by  more  than  one  FEPR  linked  to  the  current  field,  the 
FEPR  invoked  is  the  first  FEPR  in  the  FEPR- list  which  both 
references  the  event  and  for  which  the  Field  Entry 
Conditions  are  satisfied. 

FEEOO 

-  not  used. 

FEEOl  Logical  Keystroke  event  (Range) 

-  this  event  takes  a  range  of  integers  as  a  parameter,  and 
occurs  when  a  Logical  Keystroke  occurs  within  the  specified 
range.  The  Logical  Keystroke  is  either  initiated  by  the 
Logical  Keystroke  FER  or  by  the  human  user,  see  Definitive 
Note  8. 

FEE02  Field  entry  complete 

-  this  event  is  generated  by  entry  of  a  character  into  the 
last  position  in  a  field.  It  need  not  imply  that  all 
character  positions  in  the  field  have  been  entered,  since 
these  positions  are  not  necessarily  written  sequentially. 
Local  cursor  movements,  for  example,  may  be  used  during 
local  editing  to  move  the  current  entry  position  around  the 
screen. 

FEE03  Field  selected 

-  this  event  is  generated  by  the  selection  of  a  field  that 
is  linked  to  the  Selectable  Field  FEI .  The  means  by  which 
the  current  candidate  for  selection  is  actually  selected  is 
implementation  dependent. 

FEE04  Field  Waiting  Time  expired 

-  the  field  waiting  time  specified  by  the  Waiting  Time  FEI 
linked  to  the  current  field  has  been  exceeded.  Fields  not 
linked  to  such  an  FEI  are  not  subject  to  this  event. 

FEE05  Field  Entry  Instruction  violation 

-  some  of  the  defined  FEIs  imply  Field  Entry  Validation  by 
the  terminal  VT-user.  Fields  linked  to  such  FEIs  are 
candidates  for  erroneous  field  entry.  This  event  is 
generated  when  such  a  violation  occurs,  thus  enabling 
linkage  to  Field  Entry  Reactions  that  may  signal  a  visual  or 
audible  indication  of  such  a  violation,  or  alternatively  may 
terminate  local  entry  and  relinquish  WAVAR.  A  Violation  FEC 
is  available  to  allow  different  reactions  according  to  which 
FEIR  is  violated.  When  the  reaction  is  to  relinquish  WAVAR, 
the  Entry-control  index  and  FEPR  index  elements  of  the 
Context  Control  Object  will  inform  the  host  which  FEPR 
caused  the  return.  If  this  FEPR  has  made  use  of  the 
Violation  FEC,  this  FEC  will  identify  to  the  host  that  the 
violated  FEIR  was  one  of  those   in  the   list  that  forms  the 
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parameter  value   for   the   FEC,    Unique    identification  of  the 

FEIR  is   obtained  if  this   list  contains  only  one  FEIR.  The 

host  can  then  take  whatever  action  is  appropriate  to  the 
FEIR  or  FEIRs  so  identified. 

Field  Entry  Condition  Definitions 

The  elementary  Field  Entry  Conditions  for  the  mandatory 
FEPCO  are  defined  below.  Composite  conditions  can  be  built 
by  use  of  the  specified  parameters,  and  an  individual  FEPR 
can  include  multiple  conditions  in  accordance  with  20.3.5.2 
of  ISO  9040. 

A  parameter  of  type  Action  is  specified  either  as  an 
explicit  integer  value  or  as  the  current  keystroke,  see 
Definitive  Note  8.  Such  a  parameter  evaluates  to  an  integer 
of  the  type  STCO.Key  defined  in  clause  14.7.3.7.  That 
clause  also  defines  names  of  logical  keystrokes  associated 
with  these  integers.  The  local  actions  associated  with  such 
values  are  defined  in  Definitive  Note  9. 

FECOO 

-  not  used. 

FECOl  No  previous  field 

-  the  current  field  has  no  currently  defined  previous  field, 
in  the  sense  of  20.3.3.4  of  ISO  9040. 

FEC02  No  next  field 

-  the  current  field  has  no  currently  defined  next  field,  in 
the  sense  of  20.3.3.4  of  ISO  9040. 

FEC03  Start  of  field 

-  the  current  location  for  the  next  character  entry  is  at 
the  first  location  in  the  current  field. 

FEC04  End  of  field 

-  the  current  location  for  the  next  character  entry  is  at 
the  last  location  in  the  current  field. 

FEC05  At  tab  stop 

-  the  current  location  for  the  next  character  entry  is  at  a 
tabulation  stop  defined  by  the  optional  Horizontal 
Tabulation  CO  {ewos-vt-co-misc-ht )  registered  with  the  EWOS 
Registration  Authority.  If  this  CO  is  not  present  in  the 
VTE,   this  condition  is  deemed  to  be  always  satisfied. 

FEC06  At  characters  (Set  of  character  values) 
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-  the  current  location  for  the  next  character  entry  is  at  an 
array  element  whose  current  value  is  one  of  the  specified 
characters.  The  set  of  characters  is  specified  and 
interpreted  in  accordance  with  Definitive  Note  3. 

FEC07  Exits  field  (Action) 

-  the  local  action  designated  by  the  parameter  value  would 
move  the  location  for  the  next  character  entry  out  of  the 
current  field. 

FEC08  Exits  forward  path  (Action) 

-  the  local  action  designated  by  the  parameter  value  would 
move  the  location  for  the  next  character  entry  out  of  the 
forward  navigation  path  starting  at  the  current  field. 

FEC09  Exits  backward  path  (Action) 

-  the  local  action  designated  by  the  parameter  value  would 
move  the  location  for  the  next  character  entry  out  of  the 
backward  navigation  path  starting  at  the  current  field. 

FECIO  Exits  x-array  (Action) 

-  the  local  action  designated  by  the  parameter  value  would 
move  the  location  for  the  next  character  entry  out  of  the 
current  x-array. 

FECll  Exits  y-array  (Action) 

-  the  local  action  designated  by  the  parameter  value  would 
move  the  location  for  the  next  character  entry  out  of  the 
current  y-array. 

FEC12  Not  FEC  (FEC) 

-  this  condition  is  satisfied  precisely  when  the  FEC  given 
as  its  parameter  is  not  satisfied. 

FEC13  And  FECs  (Set  of  FEC) 

-  this  condition  is  satisfied  when  each  of  the  conditions  in 
the  set  comprising  its  parameter  is  satisfied. 

FEC14  Or  FECs  (Set  of  FEC) 

-  this  condition  is  satisfied  when  at  least  one  of  the 
conditions  in  the  set  comprising  its  parameter  is  satisfied. 

FEC15  Violation  (Set  of  FEIR  Identifiers) 

-  this  condition  is  provided  for  use  in  conjunction  with  the 
Field  Entry  Instruction  Violation  FEE.  Its  parameter  is  an 
FEIR-list  specified  as  a  set  of  FEIR  identifiers.  Each 
identifier  is  a  pair  <FEICO-name,  index>  where  index  is  an 
integer  addressing  a  record  in  the  FEICO  whose  name  is 
specified.  This  FEC  is  satisfied  if  the  FEIR  whose  violation 
generated  this  event  is  one  of  the  FEIRs  in  this  FEIR-list. 


14-40 


June  1990  Stable 


If  it  is  used  In  conjunction  with  any  other  FEE  then  this 
condition  is  true. 

FEC16  Unconditional 

-  this  condition  is  always  true.  It  is  given  for 
completeness  only,  and  has  the  same  effect  as  an  empty  set 
of  conditions  in  an  FEPR. 

Field  Entry  Reaction  Definitions 

The  Field  Entry  Reactions  for  the  mandatory  FEPCO  are 
defined  below.  The  significance  of  a  parameter  of  type 
"Action"  is  as  described  for  Field  Entry  Conditions.  A 
parameter  of  type  "ResetAttribute"  may  take  either  of  the 
two  values  "reset"  and  "noReset."  Such  a  parameter  controls 
the  effect  of  an  erase  operation  on  the  secondary  attributes 
of  the  erased  elements,  corresponding  to  the  values  "yes" 
and  •  "no"  for  the  reset-attribute  parameter  of  a  LOGICAL- 
ERASE  operation  as  defined  in  19.2.3.5  of  ISO  9040. 

FEROO 

-  not  used. 

FEROl  Transmit  updates 

-  the  host  copy  of  the  CCA  is  updated  to  correspond  to  the 
terminal  copy  by  the  transmission  of  all  undelivered  update 
operations.  The  operations  required  to  update  field 
contents  are  controlled  by  the  T-policy  component  of  the 
Field  Definition  Record  for  the  fields  concerned.  However, 
if  this  FER  generates  an  FEI  violation  in  accordance  with 
the  specifications  of  the  FEICO(s)  present  in  the  VTE,  and 
if  the  current  field  is  also  linked  to  an  FEPR  with  event 
FEE05  (FEI  violation)  and  satisfied  conditions,  then  this 
FER  is  not  performed  and  that  FEPR  is  activated;  the 
original  FEPR  is  abandoned. 

FER02  Relinquish  WAVAR 

-  the  action  described  under  Transmit  Updates  is  performed, 
followed  by  return  of  the  WAVAR  access  right  to  the  host. 
However,  if  this  FER  generates  an  FEI  violation  in 
accordance  with  the  specifications  of  the  FEICO(s)  present 
in  the  VTE,  and  if  the  current  field  is  also  linked  to  an 
FEPR  with  event  FEE05  (FEI  violation)  and  satisfied 
conditions,  then  this  FER  is  not  performed  and  that  FEPR  is 
activated;   the  original  FEPR  is  abandoned. 

FER03  Erase  field  right  (Reset  attribute) 

-  the  primary  attribute  value  is  cancelled  for  all  elements 
of    the    current    field    from    the    current    character  entry 
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location  to  the  end  of  the  field.  The  effect  on  the 
secondary  attribute  values  is  determined  by  the  reset- 
attribute  parameter  as  described  above. 

FER04  Erase  path  right  (Reset  attribute) 

-  the  primary  attribute  value  is  cancelled  for  all  elements 
of  all  unprotected  fields  in  the  forward  navigation  path 
containing  the  current  field,  from  the  current  character 
entry  location  onwards.  Note  that  the  forward  navigation 
path  may  not  terminate,  as  its  definition  in  20.3.3.4  of  ISO 
9040  does  not  prohibit  looping.  When  a  loop  is  entered 
during  this  operation,  the  operation  terminates  when  all 
elements  of  the  entered  loop  have  been  erased.  The  effect 
of  this  operation  on  the  secondary  attribute  values  is 
determined  by  the  reset-attribute  parameter  as  described 
above . 

FER05  Local  action  (Action) 

-  that  local  action  is  performed  which  is  designated  by  the 
given  parameter  value.  The  specification  of  these  local 
actions  is  given  in  Definitive  Note  9. 

FER06  Logical  Keystroke  (Action) 

-  initiate  the  FEPR  processing  which  would  occur  if  the 
given  keystroke  had  occurred.  This  may  itself  cause  the 
Logical  Keystroke  FER  and  hence  recursive  processings  of 
FERs.  Processing  of  current  FERs  is  suspended  until  this 
recursive  processing  is  complete.  During  recursive 
processing,  the  current  keystroke  is  taken  as  the  argument 
to  this  FER.  When  the  recursive  processing  is  complete,  the 
previous  keystroke  is  restored  and  processing  of  current 
FERs  is  resumed. 

FER07  Update  ST  CO  (Action) 

-  the  integer  value  corresponding  to  the  given  parameter  is 
written  to  the  Sequenced  Terminal  CO.  This  FER  will  usually 
be  followed  by  a  Transmit  Updates  or  Relinquish  WAVAR  FER  to 
communicate  the  update  to  the  application. 

FER08  Update  UT  CO  (Action) 

-  the  integer  value  corresponding  to  the  given  parameter  is 
written  to  the  Unsequenced  Terminal  CO.  This  update  will  be 
communicated  to  the  application  immediately. 

FER09  Execute  RIO  record  (RIO  record  id) 

-  an  EXECUTE -RECORD  operation  is  performed  on  the  RIO  record 
specified  in  the  parameter,  in  accordance  with  22.4.1  of  ISO 
9040. 

FEROlO  Call  RIO  record  (RIO  record  id) 
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-  a  CALL-RECORD  operation  is  performed  on  the  RIO  record 
specified  in  the  parameter,  in  accordance  with  22.4.2  of  ISO 
9040. 

FERll  Visual  indication 

-  present  a  visual  indication  in  response  to  Field  Entry 
Instruction  violations. 

FER12  Audible  indication 

-  present  an  audible  indication  in  response  to  Field  Entry 
Instruction  violations. 

FER13  Conditional  branch  (if:  FEC,  then:  Optional  sequence 
of  FER,  else  :  Optional  sequence  of  FER) 

-  if  the  condition  given  by  the  "if"  parameter  is  satisfied 
then  perform  the  sequence  of  reactions  given  by  the  "then" 
parameter,  else  perform  the  sequence  of  reactions  given  by 
the  "else"  parameter. 

FER14  Prevent  further  entry 

-  it  is  recommended  that  if  a  type-ahead  buffer  is  in  use  by 
the  local  user  interface,  this  reaction  should  prevent 
further  entry  into  the  buffer.  Attempted  entry  may  then 
sound  an  alarm  or  be  signalled  by  some  other  local  means, 
but  is  not  an  FEI  violation.  If  the  WAVAR  access  right  is 
relinquished  without  this  reaction  being  invoked,  the  buffer 
may  continue  to  accept  entries.  Entry  into  the  buffer  is 
resumed  when  WAVAR  is  next  returned  to  the  terminal.  It  is 
not  a  violation  of  this  profile  specification  if  the 
terminal  VT-user  does  not  behave  in  the  intended  manner. 

FER15  Write  disallowed  character 

-  the  most  recent  disallowed  character  is  written  as  if  it 
were  not  disallowed.  If  there  has  been  no  disallowed 
character,  the  effect  is  null.  This  FER  is  used  when  it  is 
desired  to  trap  the  entry  of  a  particular  character,  not  to 
forbid  it  but  instead  to  generate  some  other  reactions  in 
addition  to  the  character  entry. 

FER16  Write  string  (Character  string) 

-  the  character  string  given  as  a  parameter  is  written  as 
LOGICAL  TEXT  to  the  current  entry  location  without  regard  to 
FEICO  control.  If  the  end  of  the  field  is  reached  before 
the  string  has  been  written  in  its  entirety,  the  reaction  is 
terminated  prematurely. 

Field  Entry  Pilot  Update  Syntax 
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In  the  following  syntax,  ASN.l  Value  Assignments  have  been 
used  to  attach  value  references  to  values  of  type  NULL. 
This  enables  the  values  to  be  referenced  by  these  names 
alone,  without  the  need  to  follow  the  identifier  explicitly 
with  the  value  NULL. 


FEPR  DEFINITIONS  : :=  BEGIN 


FEE  : :=  CHOICE  { 

logicalKeystroke 

fee02 

fee03 

fee04 

fee05 


[1]  IMPLICIT  Range, 

[2]  IMPLICIT  NULL, 

[3]  IMPLICIT  NULL, 

[4]  IMPLICIT  NULL, 

[5]  IMPLICIT  NULL  ) 


f ieldEntryComplete 

FEE 

:=  fee02 

NULL 

f ieldSelected 

FEE 

:=  fee03 

NULL 

fieldWaitTimeExpired 

FEE 

:=  fee04 

NULL 

feiViolation 

FEE 

:=  fee05 

NULL 

FEC  : :=  CHOICE  { 
fecOl 
fec02 
fec03 
fec04 
fec05 
atChar 
exitsField 
exitsForwardPath 
exitsBackwardPath 
exitsXarray 
exitsYarray 
not 
and 
or 

violation 


fee  16 


I ]  IMPLICIT 
2]  IMPLICIT 
3]  IMPLICIT 
4]  IMPLICIT 
5]  IMPLICIT 
6]  IMPLICIT 
7]  Action, 
8]  Action, 
9]  Action, 
10]  Action, 

II]  Action, 
12]  FEC, 

13]  IMPLICIT 
14]  IMPLICIT 
15]  IMPLICIT 
f eicoName 
recordlndex 
[16]  IMPLICIT 


NULL, 
NULL, 
NULL, 
NULL, 
NULL, 

FEI . CharacterValues , 


SET  OF  FEC, 
SET  OF  FEC, 
SET  OF  SEQUENCE 

PrintableString, 

INTEGER  } , 
NULL  ) 


noPreviousField 

noNextField 

startField 

endField 

at  Tab 

unconditional 


FEC  : :=  fecOl  NULL 

FEC  : :=  fec02  NULL 

FEC  : :=  fec03  NULL 

FEC  : :=  fec04  NULL 

FEC  : :=  fec05  NULL 

FEC  : :=  feci 6  NULL 
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FER  : :=  CHOICE  { 


ferOl 

[1] 

IMPLICIT 

NULL, 

fer02 

[2] 

IMPLICIT 

NULL, 

eraseFieldRight 

[3] 

IMPLICIT 

ResetAttribute , 

erasePathRight 

[4] 

IMPLICIT 

ResetAttribute , 

local 

[5] 

Action, 

logicalKeystroke 

[6] 

Action, 

updateSTCO 

[7] 

Action, 

updateUTCO 

[8] 

Action, 

executeRIO 

[9] 

IMPLICIT 

RIORecordID, 

callRIO 

[10] 

IMPLICIT 

RIORecordID, 

ferll 

[11] 

IMPLICIT 

NULL, 

ferl2 

[12] 

IMPLICIT 

NULL, 

branch 

[13] 

IMPLICIT 

SEQUENCE  { 

if  [1] 

FEC, 

then       [2]   IMPLICIT  SEQUENCE  OF  FER  OPTIONAL, 
else       [3]   IMPLICIT  SEQUENCE  OF  FER  OPTIONAL  ), 
ferl4  [14]   IMPLICIT  NULL, 

ferl5  [15]  IMPLICIT  NULL, 

writeString  [16]   IMPLICIT  SEQUENCE  OF 

FEI .Character 
--  The  string  written  by  this  FER  is  the 
--  concatenation  of  the  strings  specified  by 
--  the  individual  FEI . Character  values.   --  ) 


transmitUpdates 

relinquishWAVAR 

visuallndication 

audiblelndication 

preventFurtherEntry 

writeDisallowedChar 


FER 
FER 
FER 
FER 
FER 
FER 


ferOl  NULL 
fer02  NULL 
ferll  NULL 
ferl2  NULL 
ferl4  NULL 
ferl5  NULL 


RIORecordID  :  :=  SEQUENCE  { 

rioName  [1]  IMPLICIT  PrintableString  OPTIONAL, 

--  optional  if  there  is  only  1  RIO  in  the  VTE 
recordID  [2]  IMPLICIT  PrintableString  } 


Range  : :=  SEQUENCE  OF  SEQUENCE  { 

[1]  IMPLICIT  STCO.Key, 
[2]   IMPLICIT  STCO.Key  OPTIONAL, 
mask  [3]   IMPLICIT  BIT  STRING  OPTIONAL  } 

--  The  first  two  values  of  each  trio  represent  an 
--  interval  of  logical  keystroke  values.     The  second 
--  value  in  each  pair  shall  not  be  smaller  than  the 
--  first  value.     If  the  second  value  is  omitted,  the 
--  interval  contains  only  the  specified  first  value. 
--  If  the  optional  mask  is  given,  then  the  value  being 
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--  tested  is  bitwise  logically  ANDed  with  the  mask 
--  before  being  compared  with  the  end  points  of  the 
--  interval. 


ResetAttribute   : :=  BOOLEAN 


reset 
noReset 


ResetAttribute 
ResetAttribute 


:=  TRUE 
:=  FALSE 


Action  : :=  CHOICE  { 


current 


[1]  IMPLICIT  STCO.Key, 
[2]  IMPLICIT  NULL  } 


currentKeystroke      Action  : :=  current  NULL 

--  The  ASN.l  module  STCO  is  defined  in  the  specification  of 
--  the  Sequenced  Terminal  CO  in  clause  14.7.3.     STCO.Key  is 
--an  integer  type  with  a  named  number  list,  each  named 
--  number  representing  a  specific  logical  keystroke  as 
--  defined  for  that  CO. 


END  *(FEPR  DEFINITIONS)* 

FEPCO  "mandatory- fepco"  Initial  Content 

For  each  FEPRxx,  xx  identifies  the  integer  value  to  be  used 
as  "feprList  recordlndex"  in  FDCOUpdate  operations. 
FEPCOUpdate  operations  must  use  an  "index"  greater  than  127. 
The  FEPR  contents  are  specified  in  terms  of  ASN.l  Value 
Notation  appropriate  to  the  FEPCO  Update  Syntax  specified 
above.  Note  that  "shiftTab"  is  a  named  integer  of  type 
STCO.Key.  The  local  action  it  designates  is  defined  in 
Definitive  Note  9  to  be  movement  of  the  current  character 
entry  position  to  the  first  location  of  the  next  field  in 
the  forward  navigation  path. 

FEPR  No      Component  ASN.l  Description 


FEPROO 


Not  used  -■ 


FEPROl        FEE  logicalKeystroke  {   {  0,   65535  }  } 

FEC  unconditional 

FEROl  updateSTCO  currentKeystroke 

FER02  relinquishWAVAR 


FEPR02        FEE  f ieldEntryComplete 

FEC  noNextField 
FER  relinquishWAVAR 
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FEPR03 

FEE 

f ieldEntryComplete 

FEC 

not  noNextField 

FER 

local  shiftTab 

FEPR04 

FEE 

f ieldSelected 

FEC 

unconditional 

FER 

re linqui shWAVAR 

FEPR05 

FEE 

f leldWaitTlmeExpired 

FEC 

noNextField 

FER 

re 1 inqui shWAVAR 

FEPR06 

FEE 

fieldWaitTimeExpired 

FEC 

not  noNextField 

FER 

local  shiftTab 

FEPR07 

FEE 

feiViolation 

FEC 

unconditional 

FER 

visuallndication 

FEPR08 

FEE 

feiViolation 

FEC 

unconditional 

FER 

audiblelndication 

FEPR09- 

FEPR127  --  Reserved  -- 


14.8.3.4    Profile  Arguments 

rl  -  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter  x-bound.  It  takes  an 
integer  value  greater  than  zero.  Default  is  80. 

r2  -  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter  y-bound.  It  takes  an 
integer  value  greater  than  zero.  Default  is  24. 

r3  -  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter  z -window.  It  takes  an 
integer  value  greater  than  zero.     Default  is  1. 

r4  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter  repertoire-assignment. 
The  value  for  the  VTE-parameter  repertoire-capability 
is  implied  by  the  number  of  occurrences  of  this  profile 
argument.  Default  is  a  single  occurrence  with  the 
value      {value      iso2022      {'2842'H))      of     ASN.l  type 
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CDS .RepertoireAssignment  as  defined  in  ISO  9041, 
designating  the  GL  set  ISO  2375  Reg.  No.  6  (ASCII). 

r5  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter  font-assignment.  The 
font -assignment -type  component  of  a  font -assignment 
value  is  an  ASN.l  OBJECT  IDENTIFIER  that  designates  a 
registered  sjmtax  and  semantics  for  the  font- 
assignment-value  component.  The  value  for  the  VTE- 
parameter  font- capability  is  implied  by  the  number  of 
occurrences  of  this  profile  argument.  If  there  are  no 
explicit  occurrences  of  this  profile  argument  then  the 
font- capability  and  font -assignment  VTE-parameters  take 
the  default  values  specified  in  ISO  9040. 

r6  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  DO-emphasis.  The  syntax 
and  semantics  for  this  VTE-parameter  are  specified  in 
Definitive  Note  6,  and  for  this  profile  argument  are 
specified  in  B.17.4  of  ISO  9040.  The  default  value  for 
the  occurrence  corresponding  to  each  unspecified 
subattribute  is  the  ASN.l  PrintableString  of  length  1 
specifying  the  explicit  modal  default  value  for  that 
subattribute , 

r?  ~  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameters 

f o r e g r o u n d - c o  1  o u r  -  c a p ab i 1 i t y  and 
background-colour-capability.  Default  is  8.  This 
argument  is  identified  by  the  identifier  for  the 
VTE-parameter  foreground-colour-capability  for  display 
object  A. 

r8  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter 

foreground-colour-assignment.  The  default  values  for 
unspecified  occurrences  of  this  profile  argument  are 
the  corresponding  values  from  the  ordered  list 
{"white,"  "black,"  "red,"  "cyan,"  "blue,"  "yellow," 
"green,"  "magenta").  There  are  no  default  values  if 
the  value  of  the  VTE-parameter  foreground-colour- 
capability  exceeds  8. 

r9  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter 

background-colour-assignment.      The   default  values  for 
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unspecified  occurrences  of  this  profile  argument  are 
the  corresponding  values  from  the  ordered  list 
{"black,"  "white,"  "cyan,"  "red,"  "yellow,"  "blue," 
"magenta,"  "green").  There  are  no  default  values  if 
the  value  of  the  VTE-parameter  background-colour- 
capability  exceeds  8. 

rlO  -  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter  max-f ield-elements . 
Default  is  1 . 

rll  -  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter  access-outside-f ields . 
Default  is  "not  allowed." 

rl2  -  is  mandatory  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter  CO-access  for  the  Field 
Definition,  Field  Entry  Instruction,  Field  Entry  Pilot, 
Transmission  Policy,  Sequenced  Application,  Unsequenced 
Application,  Sequenced  Terminal,  and  Unsequenced 
Terminal  control  objects.  If  the  VT-association 
initiator  is  the  terminal  VT-user,  it  takes  the  value 
"WACA,"  otherwise  it  takes  the  value  "WACI . "  This 
argument  is  identified  by  the  identifier  for  CO-access 
for  control  object  UA. 

rl3  -  is  optional,  may  occur  a  number  of  times  and  provides 
for  the  negotiation  of  a  value  for  the  VTE-parameter 
CO-name  for  optional  registered  COs .  By  default  no 
optional  COs  are  invoked. 

rl4  -  is  optional,  may  occur  a  number  of  times  and  provides 
for  the  negotiation  of  a  value  for  the  VTE-parameter 
CO-type-identif ier  for  optional  registered  COs.  The 
particular  generic  type  concerned  is  determined  from 
the  CO- type-identifier  by  the  register  entry.  The 
value  vt-b-sco-nullrio  selects  an  empty  RIO.  An 
occurrence  of  the  previous  argument  specifies  the 
presence  of  an  optional  CO  in  the  VTE-profile.  An 
occurrence  of  this  argument  is  required  for  every 
occurrence  of  the  previous  argument.  By  default  no 
optional  COs  are  invoked. 

rl5  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-repertoire- 
assignment  for  the  main  device.  Default  is  "null"  for 
each  unspecified  occurrence. 
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rl6  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter  device -font- assignment 
for  the  main  device.  Default  is  "null"  for  each 
unspecified  occurrence. 

rl7  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device -emphasis  for  the 
main  device .  The  syntax  and  semantics  for  this  VTE- 
parameter  are  specified  in  Definitive  Note  6,  and  for 
this  profile  argument  are  specified  in  B.17.4  of  ISO 
9040.  Default     is     "null"     for     each  unspecified 

occurrence . 

rl8  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter 

device-foreground-colour-assignment  for  the  main 
device.  Default  is  "null"  for  each  unspecified 
occurrence . 

-  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter 
device-background-colour-assignment  for  the  main 
device.  Default  is  "null"  for  each  unspecified 
occurrence . 

-  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter 
device -minimum-X- array- length  for  the  main  device.  It 
takes  an  integer  value  greater  than  zero.  Default  is 
the  value  of  x-bound  for  the  display  object. 

r21  -  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter 

device-minimum-Y-array- length  for  the  main  device.  It 
takes  an  integer  value  greater  than  zero.  Default  is 
the  value  of  y-bound  for  the  display  object. 

r22  -  is  optional,  may  occur  a  number  of  times  and  provides 
for  the  negotiation  of  additional  values  for  the  VTE- 
parameter  device-control-object  for  the  main  device. 
By  default  there  are  no  additional  values. 

r23     -  is    a    special    profile    argument  identified    by  the 

special-prof ile-arg-ident   "Pp-1."  It   is  optional  and 

provides  for  the  negotiation  of  a  printer  device. 
Default  is  "false." 


14-50 


June  1990  Stable 


r24  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter  device-repertoire- 
assignment  for  the  printer  device.  Default  is  "null" 
for  each  unspecified  occurrence. 

r25  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter  device -font -assignment 
for  the  printer  device.  Default  is  "null"  for  each 
unspecified  occurrence. 

r26  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device -emphasis  for  the 
printer  device.  The  syntax  and  semantics  for  this  VTE- 
parameter  are  specified  in  Definitive  Note  6,  and  for 
this  profile  argument  are  specified  in  B.17.4  of  ISO 
9040.  Default     is     "null"     for     each  unspecified 

occurrence . 

r27  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter 

device-foreground-colour-assignment  for  the  printer 
device.  Default  is  "black"  for  each  unspecified 
occurrence . 

r28  -  is  optional,  may  occur  a  number  of  times  in  an 
ordered  list  and  provides  for  the  negotiation  of  a 
value (s)  for  the  VTE-parameter 

device-background-colour-assignment  for  the  printer 
device.  Default  is  "white"  for  each  unspecified 
occurrence . 

r29  -  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter 

device-minimum-X-array- length  for  the  printer  device. 
It  takes  an  integer  value  greater  than  zero.  Default 
is  the  value  of  x-bound  for  the  display  object. 

r30  -  is  optional  and  provides  for  the  negotiation  of  a 
value  for  the  VTE-parameter 

device -minimum-Y-array- length  for  the  printer  device. 
It  takes  an  integer  value  greater  than  zero.  Default 
is  the  value  of  y-bound  for  the  display  object. 

r31  -  is  optional,  may  occur  a  number  of  times  and  provides 
for  the  negotiation  of  additional  values  for  the  VTE- 
parameter  device-control-object  for  the  printer  device. 
By  default  there  are  no  additional  values. 
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14. 8 . 3 . 5    Profile  Dependent  Control  Objects 

This  profile  uses  the  OIW  registered  Control  Objects  SA,  UA, 
ST  and  UT.  The  profile  defined  values  are  specified  in  the 
body  of  this  profile.  The  CO  specifications  require  the 
usage  of  each  CO  to  be  specified  in  the  profile.  This  is  as 
follows . 


14.8.3.5.1  Sequenced  Application  CO 

This  Control  Object  is  defined  in  clause  14.7.1.  It 
has  co-category  "symbolic."  Update  of  this  CO  with  the 
value  "audible_alarm"  sounds  an  audible  alarm  in  the 
terminal.  Update  with  the  value  "visual_alarm" 
generates  a  visual  indication  of  a  signal  from  the 
application.     All  other  values  have  no  effect. 

14 . 8 . 3 . 5 . 2  Unsequenced  Application  CO 

This  Control  Object  is  defined  in  clause  14.7,2.  It 
has  CO-category  "symbolic."  Update  of  this  CO  with  the 
value  "audible_alarm"  sounds  an  audible  alarm  in  the 
terminal.  Update  with  the  value  "visual_alarm" 
generates  a  visual  indication  of  a  signal  from  the 
application.     All  other  values  have  no  effect. 


14.8.3.5.3  Sequenced  Terminal  CO 

This  Control  Object  is  defined  in  clause  14.7.3.  It 
has  CO-category  "integer."  It  is  updated  by  the  Update 
ST  CO  FER,  and  may  be  used  to  communicate  uninterpreted 
keystrokes  to  the  application. 


14.8.3.5.4         Unsequenced  Terminal  CO 

This  Control  Object  is  defined  in  clause  14.7.4,  It 
has  co-category  "integer."  It  is  updated  by  the  Update 
UT  CO  FER  and  is  used  to  communicate  uninterpreted 
keystrokes  to  the  application  urgently. 

.8.3.6     Profile  Notes 


14 ■ 8 . 3 . 6 . 1  Definitive  Notes 

1.       The  WI  control  object  provides  a  mechanism  for  the 
application  VT-uscr  to  specify  a  time  in  which  all 
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the  fields  of  a  form  must  be  completed.  The 
terminal  VT-user  starts  the  timer  at  the  time  when 
it  receives  WAVAR.  If  the  timer  expires,  further 
entry  by  the  device  is  stopped,  all  undelivered 
updates  are  transmitted,  and  WAVAR  is 
relinquished.  Hie  undelivered  updates  are 
transmitted  followed  by  an  update  to  this  control 
object.  The  WT  update  is  made  using  the  current 
value  of  the  WT  control  object.  The  device- 
control-object  VTE-parameter  is  used  to  link  this 
CO  to  the  input  device  that  it  controls .  The  data 
element  of  this  CO  specifies  the  waiting  time  in 
seconds.  A  zero  value  signifies  that  a  Form 
Waiting  Time  is  not  to  be  used.  The  initial  value 
of  this  data  element  is  zero. 

2.  If  there  are  two  or  more  Character-oriented  FEIs 
of  the  same  type  associated  with  the  same  field, 
they  are  equivalent  to  a  single  FEI  of  that  type 
whose  parameter  is  the  concatenation  of  the 
individual  parameter  values . 

3.  The  following  parameteric  FEIs  and  FECs  defined  in 
clause  14.8.3.3  test  equality  of  characters: 

Allowed  First  Characters  FEI 
Allowed  Characters  FEI 
Disallowed  Characters  FEI 
Allowed  String  Values  FEI 
Allowed  Numeric  Values  FEI 
At  Characters  FEC 

The  characters  for  each  such  FEI  or  FEC  are 
specified  by  a  parameter  that  includes  an  optional 
set  of  secondary  attributes.  If  this  set  is 
included,  the  test  is  on  both  primary  and 
secondary  attributes;  otherwise  it  is  on  primary 
attributes  only.  If  the  test  is  on  primary 
attributes  only,  then  characters  which  pass  the 
test  are  allowed,  disallowed  or  accepted,  as 
appropriate,  irrespective  of  the  values  of  their 
secondary  attributes.  The  set  of  secondary 
attributes  need  not  specify  an  explicit  value  for 
every  secondary  attribute;  i-n  particular  the  empty 
set  is  permissible.  Default  values  are  used  for 
unspecified  secondary  attributes.  These  are 
determined  in  accordance  with  Definitive  Note  4. 

4.  The  parameter  values  for  a  number  of  FEIs,  FECs 
and   FERs    require   default   values    to   be   used  for 
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secondary  attributes  when  such  values  are  not 
specified  explicitly  by  the  parameter.  The  first 
choice  default  for  each  secondary  attribute  value 
is  the  field  modal  attribute  value  at  the  time 
that  the  FEI ,  FEC  or  FER  is  accessed.  A  first 
choice  default  value  of  "null"  is  resolved  as 
specified  in  19.2.3.1  of  ISO  9040  for  the  LOGICAL- 
TEXT  update  operation. 

When  the  Character  oriented  FEIs  associated  with  a 
particular  field  have  characters  in  common,  the 
precedence  algorithm  given  below  is  used. 

The  Allowed  First  Characters  FEI  takes  precedence 
over  the  Allowed  Characters  and  Disallowed 
Characters  FEIs  for  field  character  position  k=l. 
The  Disallowed  Characters  FEI  takes  precedence 
over  the  Allowed  Gh.aracters  FEI  for  all  field 
character  positions. 

The  following  example  illustrates  the  conflict 
resolution  algorithm.  When  a  particular  field  is 
linked  to  the  following  three  Character  oriented 
FEIs: 

Allowed  First  Characters  =  a 
Allowed  Characters  =  a,b 

Disallowed  Characters        =  a 

the  field  must  be  entered  with  the  letter  "a"  in 
the  first  character  position  of  the  field.  The 
remaining  character  positions  in  the  field  are 
limited  to  containing  the  letter  "b . "  Therefore 
field  entry  would  be  limited  to  a  form  such  as 
"abbbb.  ..." 

The  following  syntax  and  semantics  is  mandatory 
for  the  emphasis  and  device-emphasis  VTE- 
parameters.  The  scheme  of  B.17.3  of  ISO  9040  is 
to  be  adopted  except  that  the  maximum  length  for 
an  ASN.l  PrintableString  used  as  an  emphasis  value 
is  increased  from  6  characters  to  8  characters. 
Values  "B"  (Boxed)  and  "C"  (Encircled)  are  deleted 
from  subattribute  "b."  Two  further  subattributes 
are  added,  denoted  by  "g"  and  "h."  The  table  of 
allowed  character  values,  ISO  6429  SET  GRAPHIC 
RENDITION  parameter  values  and  associated 
semantics  given  in  B.17.3  of  ISO  9040  is  augmented 
by  the  addition  of: 
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Subattribute  "g"  values 

=  "I"  3      Italicized  characters 
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=  "U"    *    23      Upright,  not  Italicized 

characters 
=  "  "  -      No  change 

As  in  B.17.3  of  ISO  9040,  *  indicates  the  value 
which  is  the  explicit  modal  default  value  for  the 
subattribute .  Not  all  the  values  of  this  scheme 
need  to  have  a  1-1  correspondence  with  emphasis 
levels  available  on  the  real  device.  The  device 
object  defines  the  real  mapping. 

7.  When  default  values  are  defined  for  a  multiple- 
occurrence  profile  argument  and  fewer  occurrences 
are  negotiated  than  are  required  by  the  value  of  a 
parent  VTE-parameter ,  the  remaining  occurrences 
still  take  the  specified  default  values. 

8.  Every  action  corresponding  to  the  operation  of  an 
object  updating  device  shall  be  assigned  a  non- 
negative  integer  value.  This  value  shall  be 
interpreted  as  a  logical  keystroke  in  accordance 
with  the  definit  ions  of  the  Sequenced  Terminal  CO 
and  Unsequenced  Terminal  CO  in  clauses  14.7.3  and 
14,7.4. 

Values  in  the  range  0-255  are  used  to  generate 
entry  of  characters  into  the  Display  Object  from 
the  available  repertoires.  Values  greater  than 
255  generate  the  Logical  Keystroke  FEE  and  thus 
have  effects  that  are  under  the  control  of  the 
FEPCOs  present  in  the  VTE. 

9.  A  minimum  set  of  local  actions  is  defined  within 
this  profile,  but  implementors  may  extend  this  as 
required.  A  host  implementation  thus  may  not  know 
what  local  action  is  being  over-ridden  when  it 
requests  that  a  particular  logical  keystroke 
should  be  notified  to  the  host.  To  prevent  this 
from  limiting  the  capabilities  of  the  terminal, 
two  keystroke  combinations  that  differ  only  in  the 
inclusion  or  otherwise  of  the  ALT  key  are  required 
to  have  the  same  potential  local  action.  Host 
implementations  are  advised  not  to  over-ride  the 
action  of  both  such  keystrokes. 

The  defined  minimum  set  of  local  actions  concerns 
control  of  the  current  entry  location.  At  any 
time  when  the  terminal  possesses  the  WAVAR  access 
right,  there  is  a  well-defined  Display  Object 
array  element  which  is   the  current  candidate  for 
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update  by  a  character  entry  operation,  as 
described  in  Informative  Note  4.  If  this  element 
lies  outside  of  any  field,  or  within  a  protected 
field,  update  is  prohibited  unless  the  negotiated 
value  of  the  VTE-parameter  access-outside-f ields 
is  "yes,"  but  the  array  element  is  still  defined. 
Neither  this  location  nor  that  of  any  cursors 
which  the  implementation  may  use  to  indicate  such 
elements  is  recorded  in  the  CCA.  It  is  separate 
from  the  current  position  of  either  the  display 
pointer  or  the  logical  pointer,  and  movement  of 
this  entry  location  is  a  purely  local  action. 


Table  14.2. 

Local  actions  that 

move 

entry  location 

Name 

Unshifted  action 

Shifted  action 

lef tArrow 

X  =  X-  1 

k  =  k-1 

rightArrow 

X  =  x+1 

k  =  k+1 

upArrow 

y  =  y-1 

f  =  f-1,  k  =  1 

downArrow 

y  =  y+1 

f  =  f+1,  k  =  1 

home 

(x,y,z)  =  "start-y" 

(k,f,z)  =  "start-k" 

end 

(x.y.z)  =  "end-y" 

(k,f,z)  =  "end-k" 

pageUp 

z=z-l,  x=l,  y= 

1 

z  =  z-1,  f  =  1,  k  =  1 

PageDown 

z  =  z+1 ,  x  =  1 ,  y  = 

1 

z  =  z+1 ,  f  =  1 ,  k  =  1 

tab 

f  =  next(f) ,  k  =  1 

backTab 

f  =  previous (f),  k  =  1 

The  names  given  in  the  first  column  of  table  14.2 
are  the  identifiers  of  named  integers  of  type 
STCO.Key.  The  ASN.l  module  STCO  is  defined  as 
part  of  the  specification  of  the  Sequenced 
Terminal  Control  Object  in  clause  14.7.3.  These 
identifiers  or  the  corresponding  integers  are  used 
to  designate  the  local  actions  specified  in  the 
second  column.  If  the  initial  lower  case  letter 
of  such  a  name  is  converted  to  upper  case  and 
prefixed  with  "shift"  then  it  designates  the  local 
action  specified  in  the  third  column. 

In  this  table,  "="  is  used  as  an  assignment 
operator.  The  unshifted  actions  reference  array 
elements  by  normal  (x,  y,  z)  coordinates  while  the 
shifted  actions  reference  them  by  logical  (k,  f, 
z)      coordinates.  The      values      next(f)  and 

previous (f)  are  defined  in  19.1.3.2.2  of  ISO  9040, 
"start-k"   and  "end-k"   are  defined  in  19.1.3.5  of 
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ISO  9040,  and  "start-y"  and  "end-y"  are  defined  in 
19.1.1.4  of  ISO  9040. 

If  the  initial  or  final  coordinate  values  are 
undefined  then  the  local  action  is  implementation- 
dependent.  However,  a  host  implementation  can  use 
the  mandatory  FEPCO  to  control  the  behavior  in 
such  circumstances.  Field  Entry  Conditions  are 
provided  to  test  whether  a  particular  local  action 
would  make  the  entry  location  leave  the  current 
field  or  navigation  path,  as  defined  in  clause 
14.8.3.3. 

10.  If  the  VTE-parameter  access-outside-f ields  takes 
the  value  "allowed",  when  data  entry  terminates, 
the  display  pointer  shall  be  aligned  with  the 
current  entry  location  by  an  explicit  or  implicit 
addressing  operation.  In  this  way,  the  value  of 
the  display  pointer  notifies  the  application  of 
the  current  entry  location. 

11.  Use  of  the  values  "F"  (Framed)  and  "C"  (Encircled) 
for  emphasis  subattribute  "h"  causes  groups  of 
characters  within  a  single  field  which  have  this 
subattribute  value  to  be  outlined  by  a  frame.  The 
two  subattributes  differ  only  in  that  the  external 
corners  of  the  frame  are  squared  if  value  "F"  is 
used  and  rounded  if  value  "C"  is  used.  An 
external  corner  is  where  two  lines  meet  in  a  L 
shape,  as  distinct  from  a  T  junction  and  from  the 
intersection  of  two  lines.  The  nature  of  the 
external  corner  is  controlled  by  the  subattribute 
value  of  the  array  element  on  the  inside  of  the 
corner. 

More  precisely,  a  character  box  element  is  defined 
to  be  within  frame  (f,z)  if  it  is  in  the  field 
with  coordinates  (f,z)  and  has  either  the  framed 
or  encircled  attribute.  A  character  box  element 
is  defined  to  be  without  frame  if  either  it  is  not 
in  any  field  or  it  does  not  have  either  the  framed 
or  encircled  attribute.  In  the  image  of  a  y-array 
on  the  real  device,  a  line  is  drawn  between  two 
adjacent  images  of  character  box  elements  if  they 
are  within  different  frames,  or  if  one  is  within  a 
frame  and  one  is  without  frame.  In  addition  if  a 
character  box  element  is  within  some  frame,  a  line 
is  drawn  along  any  edge  of  that  element  which  is 
not     in    common    with    any    other    character  box 
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element,  i.e.,  along  any  edges  which  are  part  of 
the  image  of  the  boundary  of  the  Display  Object. 

14.8.3.6.2  Informative  Notes 

1.  Updates  by  the  application  VT-user  (only  possible 
within  the  z -window)  are  not  necessarily 
immediately  imaged  to  the  (human  user  of  the) 
terminal  VT-user  unless  the  real  window  of  the 
device  is  currently  positioned  over  such  an 
update.  Such  updates  may  move  the  real  window  if 
a  VT-DELIVER  indication  is  received. 

When  WAVAR  is  relinquished  by  the  application 
VT-user  the  window  may  be  moved  so  that  the  field 
addressed  by  the  CCO  is  within  the  window. 

Application  VT-user  addressing  operations  that 
advance  z  to  a  higher  address  which  is  outside  of 
the  z -window  cause  the  z -window  to  move  and 
include  one  or  more  new  y- arrays  for  which  no 
fields  are  defined.  As  the  z-window  moves,  one  or 
more  y-arrays  at  lower  addresses  will  no  longer  be 
included  in  the  z-window.  The  field  definition 
records  for  such  y-arrays  are  implicitly  deleted. 

2.  Several  of  the  descriptions  of  Field  Entry 
Instructions  refer  to  'empty'  array  elements  of 
the  Display  Object.  This  is  to  be  interpreted  in 
the  sense  of  13.2  of  ISO  9040.  Note  that  in  this 
sense  an  array  element  containing  a  space 
character  is  not  empty.  The  representation  of  an 
empty  array  element  on  the  real  device  is 
implementation-dependent,  but  for  this  reason  it 
is  recommended  that  the  representation  used  should 
be  distinct  from  that  of  a  space  character. 

3.  The  descriptions  of  a  number  of  Field  Entry 
Conditions  refer  to  the  current  field  and  to  the 
current  location  for  the  next  character  entry. 
Typically  this  current  location  will  be  indicated 
to  the  human  user  by  a  visible  cursor.  When  this 
location  lies  within  a  defined  field,  that  field 
is  the  current  field  and  the  Entry  Invoke 
Character  FEI  may  be  used  to  specify  the  nature  of 
the  visible  cursor.  However,  a  terminal 
implementation  may  allow  the  visible  cursor  to  be 
moved  outside  of  any  defined  field.  While  this  is 
so,      the      representation      of      the      cursor  is 
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implementation  dependent,  the  current  field  is 
undefined  and  no  FEPRs  are  active. 


14 . 8 . 3 . 7    Specific  Conformance  Requirements 
For  further  agreement. 

14.8.4       X3  Profile 

OIW  VTE-Profile    X3-1989  (  rl ,  r2,  r3,  r4,  r5,  r6  ) 
14.8.4.1  Introduction 

This  profile  provides  support  for  CCITT  X.3  PAD  compatible 
operation. 

The  purpose  of  this  profile  is  two-fold: 

o  to  provide  a  transitional  environment  for  applications 
that  assume  the  availability  of  X.3  parameters  with 
which  to  control  the  behavior  of  the  terminal -system. 

o  to  facilitate  a  gateway  function  between  ISO-VTP  and 
X.3. 


14. 8 .4. 2  Association  Requirements 

14.8.4. 2.1  Functional  Units 

The  Structured  CO  Functional  Unit  is  mandatory. 

The  Urgent  Data  Functional  Unit  is  optional. 

14.8.4.2.2  Mode 

This  is  an  A-mode  profile. 

14.8.4.3  Profile  Body 

Display-objects  = 
{ 

{ 

display-object-name  =  Dl , 

DO-access  =  prof ile-argument-rl , 

dimensions  =  "one," 
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X- dimension  = 
{ 

x-bound  =  "unbounded," 

x-addressing  =  "not-permitted," 

x-absolute  =  "no," 

x-window  =  0 
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repertoire-assignment       =  <ESC>  2/5  2/15  4/2 

*(  VTS  Transparent  Set  )* 

). 

{ 

display-object-name  =  D2 , 

DO-access  =  opposite  of  prof ile-argument-rl , 

dimensions  =  "one," 

X- dimension  = 


{ 


X- bound 
X- addressing 
x-absolute 
X- window 


repertoire -assignment 
), 


=  "unbounded," 

=  "not-permitted," 

=  "no," 

=  0 

=  <ESC>  2/5  2/15  4/2 

*(  VTS  Transparent  Set  )* 


). 


Control-obj ects  = 
{ 

{  *(  PAD  - 

Each  element  of  the  PAD  CO  represents  a  CCITT  PAD 
parameter.  The  CO-element-id  of  each  element  has  been 
chosen  so  that  it  would  be  same  value  as  the  CCITT  PAD 
parameter  number  that  it  represents .  The  PAD  CO  is 
used  both  to  set  CCITT  PAD  parameter-equivalent  values 
and  to  reply  to  an  update  to  the  READ  CO.  See 
Definitive  Note  25  for  conventions  concerning  updates 
to  this  CO.  )* 


CO -name 
CO -structure 
co-access 
co-priority 
CO- trigger 

{  *(  X.3  parameter 
CO-element-id  = 
CO-category  = 
co-size  = 

{  *(  X.3  parameter 
CO-element-id  = 
CO-category  = 
co-size  = 

{  *(  X.3  parameter 
CO-element-id  = 
CO-category  = 
CO-size  = 


)* 


=  PAD, 
=  22, 
=  "NSAC," 
=  "normal," 
=  "not-selected," 

1  --  PAD  recall 
1. 

"transparent, " 
8  }, 

2  --  PAD  echo  )* 
2, 

"boolean," 
1  ). 

3  --  Data  Forwarding  Character  )* 

"boolean, " 
7  ), 
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*(  X.3  parameter  4  --  Idle  Timer  Delay  )* 

CO -element -id    =  4, 

CO- category        =  "integer," 

co-size  =255  ) , 

*(  X.3  parameter  5  --  Ancillary  Device  Control  )* 
co-element- id    =  5, 
CO-category        =  "boolean," 
co-size  =  1  ) , 

*(  X.3  parameter  6  --  Control  of  PAD  Signals  )* 
co-element- id    =  6, 
CO-category        =  "transparent," 
co-size  =  4  ) , 

*(  X.3  parameter  7  --  PAD  on  receipt  of  Break  )* 
co-element- id    =  7, 
CO-category        =  "boolean," 
co-size  =  5  ) , 

*(  X.3  parameter  8  --  Discard  Output  )* 
co-element-id    =  8, 
CO-category        =  "boolean," 
co-size  =  1  ) , 

*(  X.3  parameter  9  --  Padding  After  <CR>  )* 
CO-element-id    =  9, 
CO-category        =  "integer," 
co-size  =  7  ) , 

*(  X.3  parameter  10  --  Line  Folding  )* 

co-element-id    =  10, 

co-category       =  "integer," 

co-size  =255  ) , 

*(  X.3  parameter  11  --  Device  Speed  )* 

co-element-id    =  11, 

CO-category        =  "symbolic," 

co-category        =  19  ) , 

*(X.3  parameter  12  --  Flow  Control  by  Device  )* 
co-element-id    =  12, 
CO-category        =  "boolean," 
co-size  =  1  ) , 

*(  X.3  parameter  13  --  Insert  <LF>  after  <CR>  )* 
co-element-id    =  13, 
CO-category        =  "boolean," 
co-size  =  3  ) , 

*(  X.3  parameter  14  --  Linefeed  Padding  )* 

CO-element-id    =  14, 

CO-category       =  "integer," 

co-size  =  7  ) , 

*(  X.3  parameter  15  --  Editing  )* 

co-element-id    =  15, 

co-category        =  "boolean," 

co-size  =  1  } , 
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*(  X.3  parameter  16  --  Character  Delete  )* 
co-element- id  =16, 
co-category        =  "character," 
co-repertoire-assignment  *(  any  from  CO  )* 

^  =  "void,"  "void,"  <ESC>  2/1  4/0, 

co-size  =  1  ) , 

*(  X.3  parameter  17  --  Line  Delete  )* 

co-element-id    =  17, 

co-category       =  "character," 

co-repertoire-assignment  *(  any  from  CO  )* 

=  "void,"  "void,"  <ESC>  2/1  4/0, 

co-size  =  1  }  ,  ,  xa. 

*(  X.3  parameter  18  --  Line  Display  )* 
co-element-id    =  18, 
co-category        =  "character," 
co-repertoire-assignment  *(  any  from  CO  )* 

=  "void,"  "void,"  <ESC>  2/1  4/0, 

co-size  =  1  )  ,  .  1  \* 

*(  X.3  parameter  19  --  Editing  Service  Signals  )* 

co-element- id    =  19, 

co-category        =  "transparent," 

co-size  =  8  ) , 

*(  X.3  parameter  20  --  Echo  Mask  )* 

co-element-id    =  20, 

co-category        =  "boolean," 

co-size  =  8  } , 

*(  X.3  parameter  21  --  Parity  Treatment  )* 

co-element-id    =  21, 

co-category        =  "boolean," 

co-size  =  2  ) , 

*(  X.3  parameter  22  --  Page  Wait  )* 

co-element- id    =  22, 

co-category       =  "integer," 

co-size  =  256  ) 


{  ^ (  READ  " 

Each  boolean  of  the  READ  CO  represents  an  element- id  of 
the  PAD  CO  with  the  same  identifying  value.  The  READ 
CO  is  used  to  request  the  current  values  of  PAD  CO, 
which  may  have  been  changed  by  some  local  agent.  See 
the  description  of  the  PAD  CO  for  how  the  update  to 
this  CO  modifies  the  access  to  the  PAD  CO.  )* 
co-name  =  READ, 

CO- structure  =1, 

co-access  =  opposite  of  prof ile-argument-rl , 

co-priority       =  "normal," 
co-trigger         =  "not-selected," 
co-category       =  "boolean," 
co-size  =  22 
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). 

{  *(  Break  Out-of-Band  - 

receipt     of     this     control     object     represents  "X.25 
Interrupt";     use     is     applicable    when    boolean    1  of 
element-id  7  in  PAD  CO  has  the  value  "true."  )* 
CO -name  =  BO, 

co-structure      =  1, 

CO-access  =  prof ile-argument-rl , 

co-priority       =  "urgent," 
co-trigger         =  "not-selected," 
CO-category        =  "symbolic," 
co-size  =  1 


{  *(  Break  In- Band  - 

receipt  of  this  control  object  represents  "indication 
of  break";  use  is  applicable  when  boolean  3  of  element- 
id  7  in  PAD  CO  has  the  value  "true."  )* 


), 


CO -name 

CO -structure 

CO-access 

co-priority 

co-trigger 

CO-category 

co-size 

). 


=  BI, 
=  1. 

=  prof ile-argument-rl , 
=  "normal , " 
=  "selected," 
=  "symbolic," 
=  1 
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{  *(  CUD  - 

This  CO  is  used  to  optionally  convey  Call  User  Data 
which  is  normally  carried  in  the  CCITT  PAD  call.  The 
CO  is  not  updatable,  but  may  be  given  initial  content 
value  during  association  establishment  by  special 
profile  arguments  r2  and  r3.  The  CO  is  parametric, 
with  two  elements,  one  representing  the  protocol 
identifier  field,  and  the  other  representing  the  call 
data  field  containing  user  data.  )* 
CO -name  =  CUD, 

CO-structure      =  2, 
CO-access  =  "no-access," 

(        *(  Protocol  Identifier  )* 

co-category        =  "character," 

co-repertoire-assignment  *(  VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size  =  4  } , 

{        *(  User  Data  )* 

co-category       =  "character," 

co-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size  =  124  } 

}, 

{  *(  DTE  - 

This  CO  is  used  to  optionally  indicate  the  calling  and 

called  DTE  addresses  which  are  normally  available  in  a 

true  CCITT  PAD  environment.     They  may  not  be  updated, 

but    may   be    given    initial    content   values    during  the 

association  establishment  by  special  profile  arguments 

r4  and  r5 .  )* 

CO -name  =  DTE, 

CO- structure      =  2, 

CO-access  =  "no-access," 

{        *(  Calling  DTE  address  )* 

co-element-id    =  1, 

co-category        =  "character," 

co-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size  =  15  ) , 

{        *(  Called  DTE  address  )* 
co-element-id    =  2, 
co-category       =  "character," 

co-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size  =  15  } 

}. 
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{  *(  FAC  - 

This  CO  is  used  to  optionally  indicate  the  CCITT 
facilities  which  are  normally  negotiable  during  the 
establishment  of  a  PAD  virtual  circuit.  The 
negotiation  takes  place  in  the  VT  association 
establishment  via  special  profile  argument  r6 ,  where 
the  initiator  may  propose  the  initial  content  value, 
and  the  acceptor  may  return  other  values.  )* 
CO -name  =  FAC, 

CO -structure      =  1, 
CO-access  =  "no-access," 

CO-category        =  "character," 

co-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-size  =  127 

), 


Device-objects  *(double  occurrence)*  = 
{ 

{ 

device-name  =  DEVICE-1, 

device-def ault-CO-access  =  prof ile-argument-rl , 
device-default-CO-priority  =  "normal," 
device-default-CO-trigger  =  "not-selected," 
device-def ault-CO- initial-value  =  l."true," 
device -minimum-X- array- length  =  1,  *(no  constraint)* 
device -control -object  =  {  BI ,  BO,  PAD  ), 
device-display-object  =  Dl 

*( termination    parameters     are     controlled  explicitly 

through  the  values  assigned  to  elements  3  and  4  of  the 

PAD  Control  Object)* 

). 

{ 

device-name  =  DEVICE-2, 
device-default-CO-access  = 

opposite  of  prof ile-argument-rl , 
device-default-CO-priority  =  "normal," 
device-default-CO-trigger  =  "not-selected," 
device-default-CO- initial-value  =  l."true," 
device -minimum-X- array- length  =  1,  *(no  constraint)* 
device-control-object  =  {  READ,  PAD  ), 
device-display-object  =  D2 
) 

). 

Type  of  delivery  control  =  " simple -de livery- control . " 
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14. 8 .4.4    Profile  Arguments 

rl  -  is  mandatory,  and  is  used  to  establish  the  access 
rules  for  the  display  objects  and  several  of  the 
control  objects.  This  argument  takes  one  of  the  values 
"WACI"  or  "WACA."  It  is  identified  by  the  identifier 
for  DO-access  for  display  object  Dl . 

r2  -  is  an  optional  special  profile  argument,  and  is  used 
to  set  the  intial  content  value  of  element  1  of  the  CUD 
CO.  The  value  is  encoded  from  the  binary  form  to  the 
ASN.l  type  PrintableString  according  to  the  algorithm 
described  in  Definitive  Note  24.  This  argument  is 
assigned  the  identifier  "Pp-1." 

r3  -  is  an  optional  special  profile  argument,  and  is  used 
to  set  the  initial  content  value  of  element  2  of  the 
CUD  CO.  The  value  is  encoded  from  the  binary  form  to 
the  ASN.l  type  PrintableString  according  to  the 
algorithm  described  in  Definitive  Note  24.  This 
argument  is  assigned  the  identifier  "Pp-2." 

r4  -  is  an  optional  special  profile  argument,  and  is  used 
to  set  the  initial  content  value  of  element  1  of  the 
DTE  CO.  The  value  is  encoded  from  the  binary  form  to 
the  ASN.l  type  PrintableString  according  to  the 
algorithm  described  in  Definitive  Note  24,  This 
argument  is  assigned  the  identifier  "Pp-3." 

r5  -  is  an  optional  special  profile  argument,  and  is  used 
to  set  the  initial  content  value  of  element  2  of  the 
DTE  CO.  The  value  is  encoded  from  the  binary  form  to 
the  ASN.l  type  PrintableString  according  to  the 
algorithm  described  in  Definitive  Note  24.  This 
argument  is  assigned  the  identifier  "Pp-4." 

r6  -  is  an  optional  special  profile  argument,  and  is  used 
to  set  the  initial  content  value  of  the  FAC  CO.  The 
value  is  encoded  from  the  binary  form  to  the  ASN.l  type 
PrintableString  according  to  the  algorithm  described  in 
Definitive  Note  24.  This  argument  is  assigned  the 
identifier  "Pp-5." 
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14.8.4.5    Profile  Notes 


14.8.4.5.1  Definitive  Notes 

1.  The  value  assigned  to  element  1  of  PAD  CO  selects 
the  character  used  to  return  control  to  the 
terminal -system.  The  valid  values  and  associated 
meanings  are: 


value  meaning 


0  not-permitted 

1  1/0  character  (DLE) 
32-126  graphic  character 


2.  The  value  assigned  to  element  2  of  PAD  CO 
determines  whether  or  not  characters  are  echoed  at 
the  terminal-system.  When  the  value  of  this 
boolean  is  "true,"  then  the  characters  are  echoed 
at  the  terminal -system. 

3.  The  values  assigned  to  element  3  of  PAD  CO  control 
the  forwarding  of  characters  from  the  terminal- 
system  to  the  application- system  based  on  the 
character  value.  The  defined  booleans  and 
associated  meanings  are: 


boolean  meaning 


1  alphanumeric  (A-Z,  a-z,  0-9) 

2  character  0/13  (CR) 

3  characters    1/11    (ESC),    0/7    (BEL),  0/5 
(ENQ),  0/6  (ACK) 

4  characters    7/15    (DEL) ,    1/8    (CAN) ,  1/2 
(DC2) 

5  characters  0/3  (ETX) ,  0/4  (EOT) 

6  characters    0/9    (HT) ,    0/10    (LF) ,  0/11 
(VT),  0/12  (FF) 

7  all  others  in  column  0  and  1  not  already 
included  above 


4,  The  value  assigned  to  element  4  of  PAD  CO  controls 
the  forwarding  of  characters  from  the  terminal- 
system  to  the  application-system  based  on  the 
duration  of  idle  time  elapsed  between  consecutive 
characters  received  by  the  terminal -system  from 
the  device.  The  valid  values  include  any  non- 
negative  integer  0-255;  a  value  between  1  and  255 
indicates  the  time-out  in  twentieths  of  a  second; 
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a  value  of  0  means  that  a  time-out  is  not  a 
forwarding  condition. 

5.  The  value  assigned  to  element  5  of  PAD  CO 
determines  whether  the  XON/XOFF  flow-control 
characters  (1/1  and  1/3)  are  available  for  use  by 
the  terminal -system.  When  the  value  of  this 
element  is  "true,"  then  the  flow-control 
characters  are  available,  and  the  terminal -system 
may  use  them  to  indicate  to  the  device  its 
readiness  to  accept  characters  from  it, 

6.  The  value  assigned  to  element  6  of  PAD  CO 
determines  whether  the  terminal -system  issues 
messages,  called  PAD  seirvice  signals,  to  the 
device  during  the  association.  The  specific 
service  signals  are  not  a  part  of  this  profile 
definition,  only  the  control  of  their  issue, 

7.  The  values  assigned  to  element  7  of  PAD  CO 
determine  the  behavior  at  the  terminal-system  when 
a  Break  is  received  from  the  device.  The  defined 
booleans  and  associated  meanings  are: 


boolean  meaning 


1  update  BO  CO 

2  release  the  association 

3  update  BI  CO 

4  return  control  to  terminal-system 

5  discard  data  from  application- system 


When  all  booleans  have  the  value  "false,"  there  is 
no  action  at  the  terminal-system  when  a  Break  is 
received 

A  useful  combination  of  booleans  with  value  "true" 
is  (1,3,5).  When  a  Break  is  received.  the 
terminal -system  updates  both  the  BO  CO  and  the  BI 
CO  and  discards  all  display-object  updates  from 
the  application-system  until  it  receives  an  update 
to  the  PAD  CO  for  element  8.  The  result  is  that 
the  data  path  has  been  cleared  in  both  directions. 
Notice  that  this  is  non-destructive  of  control 
object  updates, 

8.  The  value  assigned  to  element  8  of  PAD  CO 
determines  whether  or  not  the  terminal -system 
discards  data  from  the  application- system.  This 
element  works   with  element   7   to   acknowledge  the 
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receipt  of  the  Break  and  resume  normal  processing 
of  display-object  updates.  The  only  valid  value 
of  this  boolean  in  an  update  is  "false." 

9.  The  value  assigned  to  element  9  of  PAD  CO 
indicates  the  number  of  padding  characters  to  be 
generated  by  the  terminal -system  to  the  device 
following  a  carriage  return  character.  The  valid 
values  are  integers  in  the  range  0-7. 

10.  •  The    value    assigned    to    element    10    of    PAD  CO 

indicates  the  number  of  graphic  characters  sent  to 
the  device  after  which  the  terminal- system  will 
insert  a  carriage  return.  The  valid  values  are 
integers  in  the  range  0-255,  where  a  value  of  0 
means  that  this  function  is  not  performed. 

11.  The  value  assigned  to  element  11  of  PAD  CO 
indicates  the  bit- transmission  speed  of  the 
device.  This  element  may  only  appear  in  an  update 
sent  to  the  application-system  in  response  to  an 
update  of  the  READ  CO  when  boolean  11  has  the 
value  "true." 

12.  The  value  assigned  to  element  12  of  PAD  CO 
determines  whether  the  XON/XOFF  flow-control 
characters  (1/1  and  1/3)  are  available  for  use  by 
the  device.  When  the  value  of  this  element  is 
"true,"  then  the  flow-control  characters  are 
available,  and  the  device  may  use  them  to  indicate 
to  the  terminal -system  its  readiness  to  accept 
characters  from  it. 

13.  The  values  assigned  to  element  13  of  PAD  CO 
determine  under  which  situations  a  linefeed  is 
inserted  following  a  carriage  return  character. 
The  valid  values  and  associated  meanings  are: 

boolean  meaning 


1  insert     linefeed     after  carriage 
return  sent  to  device 

2  insert     linefeed     after  carriage 
return  received  from  device 

3  insert     linefeed     after  carriage 
return  echoed  to  the  device 


14.  The  values  assigned  to  element  14  of  PAD  CO 
determine  the  number  of  padding  characters 
generated   by    the    terminal -system    to    the  device 
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following  a  linefeed  character.  The  valid  values 
are  any  number  in  the  range  0-7. 

15.  The  value  assigned  to  element  15  of  PAD  CO 
determines  whether  or  not  the  terminal -system 
performs  data-editing.  When  this  CO  has  value 
"true,"  the  values  of  the  elements  3  and  4  of  the 
PAD  CO  are  ignored. 

16.  The  value  assigned  to  element  16  of  PAD  CO 
determines  which  character  is  used  in  editing  the 
line  to  signify  the  function  "delete  character." 
The  valid  values  are  the  IA5  characters,  decimal 
value  0-127.  Only  applicable  if  the  value  of 
element  15  of  PAD  CO  is  "true." 

17.  The  value  assigned  to  element  17  of  PAD  CO 
determines  which  character  is  used  in  editing  to 
signify  the  function  "delete  line."  The  valid 
values  are  the  IA5  characters,  decimal  value  0- 
127.  Only  applicable  if  the  value  of  element  15 
of  PAD  CO  is  "true." 

18.  The  value  assigned  to  element  18  of  PAD  CO 
determines  which  character  is  used  in  editing  to 
signify  the  function  "display  line."  The  valid 
values  are  the  IA5  characters,  decimal  value  0- 
127.  Only  applicable  if  the  value  of  element  15 
of  PAD  CO  is  "true." 

19.  The  value  assigned  to  element  19  of  PAD  CO 
determines  whether  the  terminal-system  provides 
for  editing  of  PAD  service  signals.  The  valid 
values  and  meanings  are  as  follows: 


value  meaning 


0  no  editing 

1  editing  as  for  a  paper  device 

2  editing  as  for  a  glass  device 

8  editing  using  one  editing  character 

32-126  editing  using  one  editing  character 
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20.  The  values  assigned  to  element  19  of  PAD  CO 
determines  which  characters  are  NOT  to  be  echoed 
to  the  device  by  the  terminal -system.  If  no  bits 
are  set,  then  all  characters  are  to  be  echoed, 
assuming  that  element  2  has  the  value  "true."  The 
defined  booleans  and  associated  meanings  are: 

boolean  meaning 


1  ^  Do  not  echo  0/13  (CR) 

2  Do  not  echo  0/10  (LF) 

3  Do  not  echo  0/11  (VT) ,  0/9  (HT) 
0/12  (FF) 

4  Do  not  echo  0/7  (BEL)  or  0/8  (BS) 

5  Do  not  echo  1/11  (ESC)  or  0/5  (ENQ) 

6  Do  not  echo  0/6  (ACK)  ,  1/5  (NAK) , 
0/2  (STX),  0/1  (SOH),  0/4  (EOT), 
1/7  (ETB)  or  0/3  (ETX) 

7  Do  not  echo  the  editing  characters 
defined  by  elements  16,  17  and  18 
of  the  PAD  CO 

8  Do  not  echo  7/15  (DEL)  or  any  of 
the  other  characters  belonging  to 
CO  or  CI  which  are  not  already 
mentioned  above 

21.  The  value  assigned  to  element  21  of  PAD  CO 
determines  the  treatment  of  parity  on  the 
characters  received  from  and  sent  to  the  device 
from  the  terminal-system.  The  defined  booleans 
and  associated  meanings  are: 

boolean  meaning 


1  parity    is    checked    on  characters 
received  from  the  device 

2  parity   is   generated  on  characters 
sent  to  the  device 

22.  The  value  assigned  to  element  22  of  PAD  CO 
determines  the  number  of  linefeeds  that  the 
terminal -system  may  send  to  the  device  before  it 
must  wait  for  input  from  the  device  request  it  to 
continue  displaying  characters.  The  range  of 
valid  values  is  0-255,  where  a  value  of  0 
indicates  that  the  terminal-system  need  never 
wait . 

23.  The  text  operation  is  the  only  operation  allowed 
on  the  display  objects. 
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24.  Special  profile  arguments  r2-r6  have  binary 
values.  However,  due  to  a  restriction  in  the 
standards  9040  and  9041 ,  those  binary  values  must 
be  conveyed  in  the  ASN.l  type  PrintableString. 
This  is  accomplished  by  mapping  the  value  of  each 
semi-octet  in  the  string  of  binary  octets  to  an 
octet  whose  value  falls  in  the  value  range  of  a 
PrintableString.  The  semi-octet  values  in  the 
range  0000  -  1001  are  mapped  into  the 
PrintableString  values  '0'  -  '9',  whereas  the 
semi-octet  values  in  the  range  1010  -  1111  are 
mapped  into  the  PrintableString  values  'A'  -  'F'. 
The  result  is  a  string  of  characters  which  is 
exactly  twice  the  length  of  the  original  string  of 
binary  octets. 

25.  The  value  of  CO-access  for  the  PAD  CO  is  "NSAC," 
however  a  convention  is  followed  that  determines 
when  a  VT-user  may  update  the  PAD  CO.  Only  the 
VT-user  with  access  to  the  Display  Object  D2  may 
update  the  PAD  CO  except  immediately  after  it  has 
updated  the  READ  CO.  When  the  READ  CO  is  received 
by  the  opposite  VT-user,  it  is  treated  as  a 
request  to  update  the  PAD  CO  with  the  parameter 
values  it  is  currently  using,  at  which  point  that 
VT-user  is  required  to  respond. 
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14. 8 .4. 5 ■ 2  Informative  Notes 

Users  of  this  profile  should  refer  to  CCITT 
Recommendations  X.3,  X.28  and  X.29  for  the 
original  model  for  this  profile. 

!.  The  following  values  for  the  elements  of  the  PAD 
CO  are  taken  from  the  CCITT  Simple  standard 
profile  and  may  prove  useful: 

element- id  Value 


possible  to  return 
control  to  the  terminal - 
system  using  0/1  (DLE) 

2  l."true" 

echo  performed  at  the 
terminal -system 

3  1. "false,"  2. "true,"  3. "true," 

4. "true,"  5. "true,"  6. "true," 
7. "true" 

forward  on  receipt  of  any 
character  in  CO  and  CI 

4  0 

no  time-out  used  for 
forwarding  condition 

5  l."true" 

terminal-system  use 
XON/XOFF  to  flow- control 
the  device 

6  l."true" 

service  signals  are  sent 

7  2. "true,"  all  others  "false" 

release  the  association 
when  a  Break  is  received 
from  the  device 

8  1. "false" 

deliver  data  to  device 


9 


do  not  pad  after  CR 


14-73 


June  1990  Stable 


10  0 

do  not  fold  the  line 

11  -  read-only 

12  l."true" 

device  use  XON/XOFF  to 
flow- control  the 
terminal - sys t em 

13  0 

do  not  insert  LF  after  CR 

14  0 

do  not  pad  after  LF 

15  1. "false" 

do  not  edit  data 

16  7/15  (DEL) 

character  delete 

17  1/8  (CAN) 

line  delete 

18  1/2  (DC2) 

line  display 

19  1 

20  0 


21  0 


22 


edit  as  for  paper 

echo  all  characters 

no  parity  checking  or 
generation 

no  page  wait 


The  following  values  for  the  elements  of  the  PAD 
CO  are  taken  from  the  CCITT  Transparent  standard 
profile  and  may  prove  useful, 

element- id  Value 

1  0 

control  may  not  be 
returned  to  the  terminal - 
system 

2  1. "false" 

the  terminal -system  does 
not  perform  character 
echo 

3  all  booleans  "false" 

no  forwarding  on 

character  value 

4  20 

forward  on  time-out  of  1 
second 
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5  1. "false" 

terminal-system  may  not 
flow-control  device 

6  1. "false" 

service  signals  are  never 
sent 

7  2. "true,"  all  others  "false" 

release  the  association 

8  1. "false" 

deliver  data  to  device 

9  0 

no  pad  after  CR 

10  0 

no  line  folding 

11  -  read-only 

12  1." false" 

device  may  not  flow- 
control  terminal -system 

13  0 

no  LF  insert  after  CR 

14  0 

no  pad  after  LF 

15  1. "false" 

no  editing  data 

16  7/15  (DEL) 

character  delete 

17  1/8  (CAN) 

line  delete 

18  1/2  (DC2) 

line  display 

19  1 

20  0 


21  0 


22 


edit  as  for  paper 

echo  all  characters 

no  parity  checking  or 
generation 


no  page  wait 

14 ■ 8 . 4 . 6    Specific  Conformance  Requirements 
None . 
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14.9  APPENDIX  A 


14. 9 . 1        Specific  ASE  Requirement 


For  specific  ASE  Requirements  identified  by  the  Upper  Layer  SIG 
for  Virtual  Terminals,  see  chapter  5,  entitled  "Upper  Layers"  in 
this  document. 


14.10  APPENDIX  B  -  CLARIFICATIONS 


14. 10. 1  Defaults 

When  a  profile  argument  is  not  present  in  either  the  offer  or 
value  list,  the  default  for  the  corresponding  VTE  parameter  is 
specified  by  ISO  9040  if  it  is  not  given  by  the  argument 
description  in  the  profile. 


14. 11  APPENDIX  C  -  OBJECT  IDENTIFIERS 

General  identifiers : 

oiw-vt  OBJECT  IDENTIFIER  : := 

{  iso(l)  identif ied-organization(3)  oiw(14)  vtsig(12)  } 


oiw-vt-pr  OBJECT  IDENTIFIER  : := 

{  oiw-vt  vteProfile(l)  } 

oiw-vt-co  OBJECT  IDENTIFIER  : := 

{  oiw-vt  controlObj ect (0)  } 

oiw-vt-co-misc  OBJECT  IDENTIFIER  : := 
{  oiw-vt-co        cotypemisc(O)  } 

oiw-vt-co-tcco  OBJECT  IDENTIFIER  : := 
{  oiw-vt-co        cotypetcco(4)  } 

Profile  defined  by  OIW  VT  SIG: 

oiw-vt-pr-telnet-1988  OBJECT  IDENTIFIER 

{  oiw-vt-pr        telnet-1988(0)  ) 

oiw-vt-pr- transparent- 1988        OBJECT  IDENTIFIER 
{  oiw-vt-pr        transparent- 1988(1)  ) 

oiw-vt-pr-forms-1989  OBJECT  IDENTIFIER 

{  oiw-vt-pr        forms-1989(2)  ) 
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oiw-vt-pr-x3-1989  OBJECT  IDENTIFIER 

{  oiw-vt-pr       x3-1989(4)  ) 

Control  Objects  defined  by  OIW  VT  SIG: 

oiw-vt-co-misc-sa  OBJECT  IDENTIFIER 

{  oiw-vt-co-misc        sa(0)  ) 

oiw-vt-co-misc-ua  OBJECT  IDENTIFIER 

{  oiw-vt-co-misc        ua(l)  ) 

oiw-vt-co-misc-st  OBJECT  IDENTIFIER 

{  oiw-vt-co-misc        st(2)  } 

oiw-vt-co-misc-ut  OBJECT  IDENTIFIER 

{  oiw-vt-co-misc       ut(3)  ) 
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TRANSACTION  PROCESSING 

Editor's  Note:  This  section  is  a  placeholder  for  future 
Transaction  Processing  (TP)  Agreements.  The -TP 
Special  -  inter es-t-  -Group  -  is-  -newly-  -  f  erned-  -and-  -held 
its -first -regular -meeting -in -March  ,--19897  Any  new 
text  from  this  group  will  be  inserted  here. 
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16.  OFFICE  DOCUMENT  ARCHITECTURE 

Editor's  Note:  There  is  international  alignment  work  taking  place 
which  is  likely  to  produce  an  International 
Standardized  Profile  (ISP)  corresponding  to  the 
level  of  ODA  functionality  being  addressed  by 
these  agreements.  The  Plenary,  in  December  1989, 
approved  a  resolution  that  this  DAP  should  be 
superseded  by  the  equivalent  internationally 
aligned  ODA  DAP  when  it  is  submitted  for 
processing  as  an  ISP.  The  intent  is  to  rename 
this  chapter  "OFFICE  DOCUMENT  ARCHITECTURE  LEVEL  3 
DAP."  The  contents  herein  were  last  modified  by 
the  Plenary  in  June  1989. 

16. 1  INTRODUCTION 

This  is  the  definition  of  an  ODA  document  application  profile  (  AP) 
named  NIST  Level  3  DAP.     The  NIST  Level  3  DAP  is  suitable  for 
interchanging  a  document  in  formatted  form,  processable  form  or 
formatted  processable  form.     This  DAP  has  been  prepared  by  the  ODA 
Special  Interest  Group  of  the  National  Institute  of  Standards  and 
Technology  (NIST)  Workshop  for  Implementors  of  OSI.     The  DAP  is 
defined  in  accordance  with  ISO  8613-1  and  CCITT  T.411  and  follows  the 
standardized  proforma  and  notation  defined  in  ISO  8613-1  proposed 
Draft  Addendum  (to  be  published). 

Note:  The      agreements      defining     this     ODA     DAP     will  be 

superseded  by  the  equivalent  internationally  aligned 
ODA  DAP  when  it  is  submitted  for  processing  as  an 
International    Standardized  Profile  (ISP). 


16.2  SCOPE  AND  FIELD  OF  APPLICATION 

This  DAP  specifies  interchange  formats  for  the  transfer  of  structured 
documents  between  equipment  designed  for  word  or  document  processing. 
Such  documents  may  contain  characters,  raster  graphics  and  geometric 
graphics  content. 

The  documents  supported  by  this  profile  range  from  simple  documents  to 
highly  structured  technical  reports,  articles  and  typeset  documents 
such  as  brochures.  This  profile  provides  a  comprehensive  level  of 
features  for  the  transfer  of  documents  between  these  systems. 

This  document  application  profile  describes  documents  which  can  be 
interchanged  in  the  following  form,  as  defined  in  ISO  8613: 

Formatted  form, 
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Processable  form,  and 
Formatted  processable  form. 

The  architecture  level  have  matching  functionalities  so  that  the 
interchange  formats  of  a  document  are  convertible  from  a  processable 
form  into  any  other  form. 

This  DAP  is  independent  of  the  processes  carried  out  in  an  end  system 
to  create,  edit  or  reproduce  which,  for  example,  may  be  by  means  of 
communication  links  or  storage  media. 


16.3  REFERENCES 

ISO  2022  Information  Processing  -  ISO  7-bit  and  8-bit  coded  character 
sets  -  Code  extension  techniques 

ISO  6937-1  Information  Processing  -  Coded  character  sets  for  text 
communication  -  Part  1 :  General  introduction 

ISO  6937-2  Information  Processing  -  Coded  character  sets  for  text 
communication  -  Part  2:  Latin  alphabetic  and  non-alphabetic  graphic 
characters 

ISO  8613-1  Information  Processing  -  Text  and  Office  Systems  -  Office 
Document  Architecture  (ODA)  and  Interchange  Format  -  Part  1 : 
Introduction  and  General  Principles 

ISO  8613-2  Information  Processing  -  Text  and  Office  Systems  -  Office 
Document  Architecture  (ODA)  and  Interchange  Format  -  Part  2:  Document 
Structures 

ISO  8613-4  Information  Processing  -  Text  and  Office  Systems  -  Office 
Document  Architecture  (ODA)  and  Interchange  Format  -  Part  4:  Document 
Profile 

ISO  8613-5  Information  Processing  -  Text  and  Office  Systems  -  Office 
Document  Architecture  (ODA)  and  Interchange  Format  -  Part  5:  Office 
Document  Interchange  Format 

ISO  8613-6  Information  Processing  -  Text  and  Office  Systems  -  Office 
Document  Architecture  (ODA)  and  Interchange  Format  -  Part  6:  Character 
Content  Architecture 

ISO  8613-7  Information  Processing  -  Text  and  Office  Systems  -  Office 
Document  Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Raster 
Graphics  Content  Architecture 

ISO  8613-8  Information  Processing  -  Text  and  Office  Systems  -  Office 
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Document  Architecture  (ODA)  and  Interchange  Format  -  Part  8:  Geometric 
Graphics  Content  Architecture 

ISO  8613-1  PDAD  . . .   "Document  Application  Profile  Proforma  and 
Notation"  (to  be  published) 

ISO  8632-1  Information  Processing  Systems  -  Computer  Graphics  - 
Metafile  for  the  storage  and  transfer  of  picture  description 
information  -  Part  1 :  Functional  Specification 

ISO  8632-3  Information  Processing  Systems  -  Computer  Graphics  - 
Metafile  for  the  storage  and  transfer  of  picture  description 
information  -  Part  3 :  Binary  Encoding 

ISO  8859-1  Information  Processing  -  8 -bit  single  byte  coded  graphic 
character  sets  -  Part  1:  Latin  Alphabet  No.  1 

ISO  8859-7  Information  Processing  -  8-bit  single  byte  coded  graphic 
character  sets  -  Part  7 :  Latin/Greek  Alphabet 

ISO  8824  Information  Processing  Systems  -  Open  Systems  Interconnection 

-  Specification  of  Abstract  Syntax  Notation  1  (ASN.l) 

ISO  8825  Information  Processing  Systems  -  Open  Systems  Interconnection 

-  Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  1 
(ASN. 1) 

CCITT  T.6  -  Facsimile  coding  scheme  and  coding  control  functions  for 
Group  4  Facsimile  Apparatus,  1984 

CCITT  T.411  Open  Document  Architecture  (ODA)  and  Interchange  Format  - 
Introduction  and  general  principles,  1988 

CCITT  T.502  Document  Application  Profile  PM.l  for  the  interchange  of 
processable  form  documents 

PrENV  ...  QUI  ODA  document  application  profile  -  processable  and 
formatted  documents  -  basic  character  content  (to  be  published) 

PrENV  . . .  Q112  ODA  document  application  profile  -  processable  and 
formatted  documents  -  extend  mixed  mode  (to  be  published) 

INTAP  ...  AE-1126  ODA  document  application  profile  ... 

PAGODA  . . .  CORE- 11  ODA  document  application  profile  -  processable  and 
formatted  documents  -  basic  character  content  (to  be  published) 

PAGODA  . . .  CORE-26  ODA  document  application  profile  -  processable  and 
formatted  documents  -  advanced  mixed  mode  (to  be  published) 
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PAGODA  . . .  Core-36  ODA  document  application  profile  -  processable  and 
formatted  document  -  enhanced  mixed  mode  (to  be  published) 


16.4  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  given  in  ISO  8613-1  are  applicable  to  this  document. 

The  following  additional  definitions  are  applicable  to  this  document. 

Generating  Support  Statement  (GSS) 

A  statement  which  states  the  range  of  support  of  an  originating 

system.     An  originating  system  generates  ODIF  data  streams.  A 

GSS  defines  a  subset  of  all  possible  data  streams  supported  by  an 

implementation  which  an  origination  capability.     A  GSS  is 

specified  by  completing  the  GSSP  defined  in  Annex  A  of  this 
document . 

Generating  Support  Statement  Proforma  (GSSP) 

A  definition  of  the  conformance  requirements  of  a  profile  in 
terms  of  a  list  of  requirements  for  implementations  to  originate 
data  streams  which  conform  to  the  profile.     A  GSSP  defines  the 
format  for  all  GSSs. 

Implementation  Characteristic  Statement  (ICS) 

A  statement  which  states  the  range  of  support  of  an 
implementation  to  a  DAP. 

Receiving  Support  Statement  (RSS) 

A  statement  which  states  the  range  of  support  of  a  receiving 
system.     A  receiving  system  interprets  ODIF  data  streams.     A  RSS 
defines  functions  and  fall-backs  supported  by  an  implementation 
with  a  reception  capability,     A  RSS  is  specified  by  completing 
the  RSSP  defined  in  Annex  A  of  this  document. 

Receiving  Support  Statement  Proforma  (RSSP) 

A  definition  of  the  conformance  requirements  of  a  profile  in 
terms  of  a  list  of  requirements,   including  fall-backs,  for 
implementations  to  receive  data  streams  which  conform  to  the 
profile.     A  RSSP  defines  the  format  for  all  RSSs. 
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16.5  POSITION  OF  THIS  DAP  IN  THE  TAXONOMY  OF  RELATED  DAPS 

There  is  only  one  DAP  currently  being  developed  by  the  NIST  ODA  SIG. 
This  DAP  is  a  Level  3  DAP,  in  relation  to  the  following  hierarchy. 

Level  1      Basic  documents  consisting  of  character  content  only. 

This  level  of  document  contains  the  functionality  found 
in  most  word  processor  products. 

Level  2      Extended  dociaments  consisting  of  character,  raster 

graphics  and  geometric  graphics  content.     This  level  of 
document  contains  enhanced  functionality  to  support 
multi-media  document  processors  evolved  from  word 
processor  precursors. 

Level  3      Advanced  documents  consisting  of  character,  raster 

graphics  and  geometric  graphics  content.     This  level  of 
docioment  contains  the  functionality  traditionally  found 
in  most  "desktop  publishing"  or  personal  publishing 
products . 


16.6  CONFORMANCE 

In  order  to  conform  to  this  DAP,  a  data  stream  representing  a  document 
must  meet  the  requirements  specified  in  clause  16.5.1. 

Clause  16.5.2  specifies  the  requirements  for  implementations  that 
originate  and/or  receive  data  streams  conforming  to  this  DAP. 


16.6.1        Data  stream  conformance 


The  following  requirements  apply  to  the  encoding  of  data  streams 
that  conform  to  this  ISP. 

The  data  stream  shall  be  encoded  in  accordance  with  the 
ASN.l  encoding  rules  defined  in  ISO  8825, 

The  data  stream  shall  be  structured  in  accordance  with 
the  interchange  format  defined  in  clause  16.8  of  this 
DAP, 

The  encoded  document  shall  be  structured  in  accordance 
with  one  of  the  document  architecture  classes  specified 
in  clause  16.7  of  this  DAP.     In  addition,  the  encoded 
document  shall  contain  all  required  constituents 
specified  for  that  class  and  contain  only  constituents 
permitted  or  required  for  that  class  as  specified  in 
clause  16.7  of  this  DAP, 
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The  encoded  constituents  shall  contain  all  required 
attributes  as  specified  in  clause  16.7  of  this  DAP, 

The  encoded  attributes  shall  have  values  within  the 
range  of  permissible  values  specified  in  clause  16.7  of 
this  DAP, 

The  encoded  document  shall  be  structured  in  accordance 
with  the  abstract  document  architecture  defined  in  ISO 
8613, 

The  encoded  document  shall  be  structured  in  accordance 
with  the  characteristics  defined  in  clause  16.6  of  this 
DAP. 


16.6.2        Implementation  conformance 

This  clause  states  the  requirements  for  implementations  claiming 
conformance  to  this  DAP. 

An  implementation  claiming  to  originate  and/or  receive  data 
streams  conforming  to  this  DAP  must  complete  a  Generator  Support 
Statement  (GSS)  and/or  Receiver  Support  Statement  (RSS)  Proforma 
as  defined  in  Annex  A  of  this  DAP. 

A  conforming  receiving  implementation  must  be  capable  of 
receiving  any  data  stream  conforming  to  this  DAP.  "Receiving" 
means  not  rejecting  a  data  stream  conforming  to  this  DAP  and 
usually,  but  not  always,   involves  recognizing  and  further 
processing  the  data  stream  elements.     The  explicit  meaning  of 
"receiving"  is  determined  by  a  RSS  defined  in  accordance  with 
Annex  A  of  this  DAP. 


16.7  CHARACTERISTICS  SUPPORTED  BY  THIS  DAP 


16.7.1  Overview 

The  NIST  Level  3  DAP,   in  accordance  with  ISO  8613,  allows 
documents  to  be  represented  in  the  following  forms: 

processable  form,  which  facilitates  the  revision  of  a 
document  by  a  recipient; 

formatted  form,  which  facilities  the  reproduction  of  a 
document  as  intended  by  the  originator; 

formatted  processable  form,  which  facilitates  the 
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reproduction  of  a  document  as  intended  by  the 
originator  or  facilitates  the  revision  of  a  document. 

16.7.1.1  Specification  of  constituents 

This  section  specifies  the  required  and  optional 
constituents  used  for  the  representation  of  documents  that 
conform  to  the  NIST  Level  3  DAP. 

Constituents  specified  as  'required'  must  occur  in  any 
document  that  conforms  to  the  NIST  Level  3  DAP. 
Constituents  listed  as  'optional'  may  or  may  not  be  present 
in  the  document  depending  upon  the  requirements  of  the 
particular  document. 

16.7.1.2  Formatted  form  documents 
Required  Constituents 

a  document  profile 

layout  object  descriptions  representing  a  specific 
layout  structure 

Optional  Constituents 

layout  object  class  descriptions  representing  a 
'partial'  generic  layout  structure 

presentation  styles 

16.7.1.3  Processable  Form  Documents 
Required  Constituents 

a  document  profile 

logical  object  class  descriptions  representing  a 
'complete'  generic  logical  structure 

logical  object  descriptions  representing  a 
specific  logical  structure 

Optional  Constituents 

layout  object  class  descriptions  representing  a 
'complete'  generic  layout  structure 


16-7 


December  '89 

layout  styles 

presentation  styles 
16.7.1.4     Formatted  Processable  Form  Docioments 
Required  Constituents 

a  document  profile 

logical  object  class  descriptions  representing  a 
'complete'  generic  logical  structure 

logical  object  descriptions  representing  a 
specific  logical  structure 

layout  object  class  descriptions  representing  a 
'complete'   generic  layout  structure 

layout  object  descriptions  representing  a  specific 
layout  structure 

Optional  Constituents 

layout  styles 

presentation  styles 

The  following  sections  describe  the  logical  and  layout 
features  that  can  be  represented  in  documents  conforming  to 
this  document  application  profile.     The  features  are 
described  in  terms  that  are  typical  of  the  capabilities  of 
current  document  processors .     The  features  are  grouped  into 
logical  features  and  layout  features  in  order  to  relate  them 
to  their  ODA  representation. 

Documents  conforming  to  this  document  application  profile 
may  contain  any  or  all  of  the  following  content 
architectures : 


a)      character  text, 

b)  raster  graphics,  and 

c)  geometric  graphics. 

.7.2        Logical  characteristics 
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16 . 7 ■ 2 ■ 1     Document  logical  structure 

The  logical  structure  of  documents  comprise  a  title, 
passages,  numbered  segments   (e.g.,   chapters,   sections  or 
numbered  paragraphs),  paragraphs,  phrases,  figures, 
footnotes  and  references.     Numbered  segments  can  be  nested 
and  automatic  numbering  systems  are  provided  for. 

The  logical  structure  of  a  document  conforming  to  this 
document  application  profile  consists  of  a  hierarchy  of 
logical  objects.     The  following  is  an  example  of  a  generic 
document  logical  structure  derived  from  this  document 
application  profile: 

Document 

Passage (s) 

Paragraph 
Text 
Footnote 

Footnote  reference 
Footnote  body 

Text 
Figure 
Text 
Figure 

Numbered  Segment 
Number 
Title 
Passage 

Paragraph 
Figure 
Numbered  Segment 


16.7.2.2    Document  structure  elements 


16 . 7 . 2 ■ 2 ■ 1  Document 

A  document  is  composed  of  a  sequence  of  numbered 
segments  or  passages  each  of  which  is  optionally  titled 
and  consists  of  a  sequence  of  paragraphs  and/or  figures 
and/or  further  passages  or  numbered  segments . 

16.7.2.2.2  Passage 

A  passage  consists  of  any  logical  sequence  of 
paragraphs,  figures,  and/or  further  passages  or 
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numbered  segments  that  can  be  regarded  as  an  entity  for 

reading  or  for  layout  presentation. 

For  example,  separate  passages  may  be  provided  for: 

a)  the  contents  to  be  placed  on  the  title  page 
of  a  report, 

b)  the  body  of  the  report,  and 

c)  the  contents  to  be  placed  In  appendices, 

A  table  is  a  particular  case  of  a  passage.  A  single 
paragraph  or  a  single  figure  is  a  simple  case  of  a 
passage . 

16.7.2.2.3  Numbered  Segment 

A  segment  is  a  part  of  a  document  which    has  an 
automatic  number  which  precedes  any  other  contents  and 
which  serves  to  uniquely  identify  the  numbered  segment. 

The  contents  of  a  numbered  segment  may  begin  with  a 
segment  title  starting  on  the  same  line  as  the  segment 
number . 

The  document  originator  may  define  different  classes  of 
numbered  segments  having  in  common  some  presentation 
features  and/or  some  layout  features.     For  example,  the 
document  originator  may  define  a  class  of  numbered 
segments  which  always  begin  on  a  new  page,  and  another 
class  of  numbered  segments  which  are  laid  out  using  a 
special  left  or  right  margin  offset. 

An  automatically  generated  segment  number  consists  of 
either  a  number  or  a  series  of  numbers  separated  by 
instances  of  an  arbitrary  specified  character  string 
separator.     In  the  case  of  a  series  of  numbers,  the 
segment  number  is  equal  to  the  automatically  generated 
segment  number,   if  any,  of  the  enclosing  segment 
followed  by  a  single  index  number  to  uniquely  identify 
the  segment. 

Index  numbers  are  generated  sequentially  within  any 
numbered  segment.  The  method  of  numbering  may  be  a 
combination  of  the  following: 

a)  Arabic  numerals, 

b)  Upper/lower  case  letters,  or 

c)  Upper/lower  case  Roman  numerals. 
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16.7.2. 2. 4  Paragraph 

A  paragraph  is  a  contiguous  amount  of  content  in  the 
intended  reading  order.     For  example,  a  paragraph  may 
contain  a  mixture  of  embedded  phrases ,   figures , 
footnote  references  and  character  text. 

A  paragraph  may  contain  zero,  one  or  more  embedded 
phrases . 

A  paragraph  may  contain  zero,  one  or  more  embedded 
figures  and,  optionally,   figure  references.  Multiple 
consecutive  figures  and/or  figure  references,  without 
intervening  text,  are  permitted. 

A  paragraph  may  contain  zero,  one  or  more  embedded 
footnote  references .     Multiple  consecutive  footnote 
references,  without  intervening  text,  are  also 
permitted. 

A  paragraph  may  comprise  a  numiber  of  character 
sequences  concatenated  together,   for  example  if  the 
character  sequences  were  separately  derived  or 
generated . 

The  document  originator  may  define  different  classes  of 
paragraphs  having  in  common  some  presentation  features 
and/or  some  layout  features.     For  example,   the  document 
originator  may  define  classes  of  paragraphs  for 
"abstract,"  "standard  paragraph,"  and  "summary." 

16.7.2.2.5  Phrase 

A  phrase  is  an  amount  of  text  content  that  is  intended 
to  be  distinguished.     The  phrase  can  be  used  to 
construct  a  paragraph  containing  sections  of  text  with 
different  presentation  features.     For  example,   in  the 
midst  of  a  paragraph  a  phrase  may  be  highlighted  to 
distinguish  a  quote. 

A  phrase  can  consist  of  one  or  more  text  content, 
references,  footnotes  or  other  phrases. 

16.7.2.2.6  Figure 
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A  figure  is  an  amount  of  geometric  graphics  or  raster 
graphics  content  designed  to  occupy  a  rectangular  area. 

One  or  more  paragraphs  can  be  associated  with  a  figure, 
for  example  to  provide  captions  or  notes. 


A  footnote  consists  of  a  footnote  reference  and  a 
footnote  body. 

The  footnote  body  is  a  contiguous  amount  of  text  that 
can  be  read  out  of  sequence  from  the  paragraph 
containing  a  reference  to  it. 

16.7.2.2.8  Footnote  reference 

A  footnote  reference  may  have  an  automatically 
generated  label  or  one  supplied  by  the  user.  (Both 
types  of  footnote  references  may  be  present.)     If  the 
label  is  automatically  generated  then  the  label  may  be 
represented  by  Arabic  numerals,  upper  or  lower  case 
Roman  numerals,  or  upper  or  lower  case  alphabetic 
characters . 

Automatically  generated  footnote  numbers  are 
incremented  sequentially  from  an  initial  value  which 
may  be  set  to  any  non-negative  value  at  the  beginning 
of  the  document  and  reset  at  any  segment  or  passage,  as 
required. 


A  general  purpose  reference  mechanism  is  provided 
within  paragraph.     For  example,  this  reference  may  be 
used  to  reference  figures,  page  numbers,  chapter 
numbers,  etc.   in  other  parts  of  the  document. 


16.7.2.2.7 


Footnote 


16.7.2.2.9 


Reference 


16.7.3 


Layout  characteristics 
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16.7.3.1     Document  layout  structure 

The  page  layout  structure  allows  for  several  pagesets 
(e.g.,   for  title  page,   foreword  and  annexes  in  addition  to 
the  main  text  body,  which  could  be  in  chapters  or  sections) 
The  body  area  of  a  page  may  contain  multiple  columns  and 
areas  for  graphics.     Header  and  footer  contents  can  also 
inc lude  f  i  gur e  s . 

The  following  is  an  example  of  a  generic  document  layout 
structure  derived  from  this  document  application  profile: 

Document 

Page  set 

Page 

Header  area 
Body  area 

Single  frame 

Multiple  columns 

Individual  frame (s) 

Mixed  set  of  frames 
Footer  area 


16.7.3.2    Document  layout  structure  elements 
16.7.3.2.1  Document 

A  document  consists  of  a  sequence  of  one  or  more  page 
sets . 


16.7.3.2.2         Page  set 

The  pages  within  a  page  set  all  have  the  same 
dimensions  and  orientation  (landscape  or  portrait)  but 
may  differ  in  layout  and/or  content  of  the  header  and 
footer  areas. 

There  may  be  an  optional  first  page  of  one  particular 
page  layout  and  this  may  be  followed  by  either  of  the 
following: 

a)  Repeated  pages  with  the  same  layout 

b)  Repeated  pages  designed  for  alternating  recto 
and  verso  layout 
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16.7.3.2.3  Page  layout 

This  document  application  profile  supports  various  page 
dimensions.     The  default  dimensions  is  the  common 
assured  reproduction  area  of  ISO  A4  and  North  American 
Letter.     In  addition,  support  is  provided  for  the 
assured  reproduction  area  of  ISO  A4  and  North  American 
Letter,  as  well  as,  the  full  page  dimensions  of  ISO  A4 
and  North  American  Letter.     Both  portrait  and  landscape 
orientations  are  supported. 

A  page  layout  consists  of: 

a)  An  optional  header  area  that  is  reserved  for 
header  contents, 

b)  A  single  body  area,  or 

c)  An  optional  footer  area  that  is  reserved  for 
footer  contents. 

Particular  header  and  footer  contents  are  associated 
with  each  page  layout . 

16.7.3.2.4  Body  area  layout 

The  body  area  may  be  subdivided  into  rectangular 
frames.     Thus  the  layout  may  consist  of  any  sequence 
of: 

a)  Single  frame  of  fixed  width,  equal  or  less 
than  body  area  width,  and  fixed  height  or 
height  adjustable  to  fit  contents, 

b)  Set  of  multiple  column  frames  of  fixed  widths 
per  column  and  fixed  height  or  height 
adjustable  to  fit  contents, 

c)  Individual  frames  with  fixed  position  and 
dimensions,  potentially  overlaid,  allowing 
for  support  of  forms, 

d)  Mixed  set  of  frames  with  various  properties, 
e.g.,  fixed-size  figure  frame  with 
fixed-sized  caption  frame  beneath  and 
adjustable  height  text  frame  beside  both. 

See  figure  16.1  for  illustrations. 

Frames  which  have  fixed  position  and  dimensions  are 
permitted  to  overlap. 
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16 . 7 . 3 ■ 2 ■ 5  Header  area  layout 

This  is  a  rectangular  area  above  the  body  area.  It 
be  subdivided  into  a  number  of  rectangular  frames,  f 
example  to  contain  textual  information  and  graphics 
such  as  company  logos . 
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Body  Area 


(a)  single  frame 


(b)  multiple  columns 


(c)  individual  frames 


(d)  mixed  set  of  frames 


Figure  16.1.     Examples  of  layout  within  body  area. 
16.7.3.2.6  Footer  area  layout 

This  is  a  rectangular  area  below  the  body  area.     It  may 
be  sub-divided  into  a  number  of  rectangular  frames,  for 
example  to  contain  textual  information  and  graphics 
such  as  company  logos . 
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Header  contents  and  footer  contents 


Header  contents  or  footer  contents  may  consist  of  a 
sequence  of  paragraphs  and/or  figures  that  are 
constrained  to  be  laid  out  entirely  within  the 
corresponding  header  or  footer  area. 

One  or  more  automatically  generated  page  numbers  may  be 
included  anywhere  within  header  contents  and/or  footer 
contents . 

Header  contents  or  footer  contents  must  not  include  any 
footnote  or  footnote  reference  or  automatic  segment 
numbers . 

16.7.3.2.8  Page  numbering 

An  automatically  generated  page  number  may  occur  at  any 
position  within  header  contents  or  footer  contents. 
Page  numbers  may  represented  in  Arabic  numerals, 
lower/upper  case  Roman  numerals  or  lower/upper  case 
letters . 

Page  numbers  are  generated  sequentially  and  the 
sequence  can  be  restarted  from  any  positive  integer 
value  at  the  beginning  of    any  page  set. 

16.7.3.2.9  Layout  of  document  logical  contents 

The  sequence  of  passages  and/or  segments  is  laid  out  in 
one  or  more  body  areas  such  that  it  flows  through  the 
sequence  of  pages  in  the  document. 

Controls  are  needed  in  order  to  break  the  flow  of 
contents  at  appropriate  points.     For  example,  following 
the  passages  to  be  placed  on  the  title  page  of  a 
document  it  may  be  required  to  control  the  flow  in 
order  to  direct  subsequent  text  onto  a  new  page  of  a 
different  page  layout. 

16.7.3.2.10  Layout  of  passage  (or  segment)  contents 

A  passage  may  be  laid  out  in  any  of  the  following  ways: 

As  separate  passages  (see  below) , 
Below  the  previous  text  within  a  containing 
passage,  or 


a) 
b) 
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c)       As  a  sequence  of  passages . 

16.7.3.2.11  Layout  of  passage  contents 

Controls  are  available  to  guide  the  layout  of  passages 
or  their  subordinate  paragraphs  and  figures. 

A  passage  can  be  positioned  at  a  fixed  position  (e.g., 
the  start)  of  a  new  body  area  or  in  a  new  frame  below 
the  previous  contents  of  a  body  area. 

In  case  of  sets  of  multiple  columns,  content  generally 
flows  from  the  bottom  of  one  column  of  the  set  to  the 
top  of  the  next  column  to  the  right. 

Regardless  of  content  type ,  the  various  paragraphs  and 
figures  in  a  passage  may  be  laid  out  within  specified 
frames . 

The  various  methods  of  subdivision  of  body  areas  may  be 
combined  with  certain  frames  being  designated  for 
flowing  text  and  other  frames  for  particular  contents. 
Thus  text  may  appear  to  flow  around  other  contents. 
For  example,   several  figures  can  be  contained  within  a 
passage  and  effect  of  text  flow  around  the  figures  and 
their  captions  can  be  produced.  See  figure  16.2  for 
illustration. 

A  new  set  of  multiple  frames  can  occur  beneath  a 
similar  set.     Thus  parallel  text  (e.g.,  multilingual) 
can  be  synchronized  or  a  table  effect  can  be  generated. 
See  figure  16.3  for  illustration. 

A  variation  of  the  table  technique  can  be  used  for 
labelling  and  annotating  paragraphs. 

A  complete  passage  can  be  constrained  to  be  contained 
in  the  same  body  area  or  frame  (by  indivisibility) . 

16.7.3.2.12  Layout  controls 

The  following  properties  may  be  specified  to  control 
where  body  area  or  page  breaks  occur: 

a)      New  column  set  (New  Layout  Object) 

This  specifies  that  the  contents  should  be  laid  out  in 
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the  first  column  (or  frame)  of  a  new  set  of  columns  (or 
frames) . 

b)      Unconditional  column  break  (New  Layout 
Object) 

This  indicates  that  the  contents  must  be  displayed  in 
the  next  column  (or  frame) . 


Body  Area 


text 


notes 


caption 


-  text  — 
continued 


■-  text  — 
continued 


Figure  16.2.     Example  of  text  flow  around  figura 


Note:  "Caption"  and  "Notes"  contain  formatted 

character  content. 
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Figure  16.3.     Example  of  synchronized  text. 

c)  Layout  object  class 

This  indicates  that  the  contents  concerned  must  be 
displayed  in  a  specified  frame,  e.g.,  to  control 
figure  positioning. 

d)  New  page  set  (New  Layout  Object) 

This  indicates  that  the  contents  should  be  laid  out  in 
a  new  page  set. 

e)  New  page  layout  (New  Layout  Object) 

This  indicates  that  the  contents  should  be  laid  out  on 
a  new  page  of  a  particular  page  layout. 
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f)  Unconditional  page  break  (New  Layout  Object) 

This  indicates  that  the  contents  must  be  displayed  in 
the  body  area  of  the  next  page. 

g)  Indivisibility 

This  indicates  that  a  passage  (segment,  paragraph  or 
figure)  must  be  laid  out  within  a  single  frame,  body 
area  or  page  set. 

h)  Same  page/same  area  (Same  Layout  Object) 

This  specifies  that  the  start  of  a  passage,  numbered 
segment,  paragraph,  or  figure,   for  example,  must  be 
laid  out  in  the  same  frame  or  body  area  as  the  end  of 
the  previous  content  (for  example,   to  keep  a  first 
paragraph  with  a  title) 

16.7.3.2.13  Layout  of  paragraph  contents 

A  paragraph  may  or  may  not  specify  its  own  margins, 
alignment  and  tab  stops.     The  indentation  of  the  first 
line  may  be  different  from  the  remainder  of  the 
paragraph.     The  separation  between  successive 
paragraphs  can  be  controlled. 

Within  a  passage  the  contents  of  a  paragraph  may  be 
laid  out  in  two  or  more  frames  to  allow  text  to  flow 
around  a  figure.     The  figure  may  or  may  not  be 
logically  associated  with  that  paragraph. 

By  using  the  widow  and  orphan  features,   layout  of 
paragraphs  can  also  be  controlled  in  order  to  determine 
how  a  paragraph  should  be  divided  across  two  pages. 

The  orphan  size  specifies  the  minimum  number  of  lines 
of  text  that  must  be  allocated  to  the  first  body  area 
or  frame . 

The  widow  size  specifies  the  minimum  number  of  lines  of 
text  that  must  be  allocated  to  the  last  body  area  or 
frame  when  a  paragraph  is  split  over  two  or  more  body 
areas  or  frames. 

16.7.3.2.14  Layout  of  figure  contents 
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A  figure  may  occur  beneath  the  previous  contents  of  a 
body  area  or  frame  or  can  be  specified  to  occupy  a 
particular  frame. 

Any  paragraphs  associated  with  the  figure,  for  example, 
to  provide  captions  or  notes,  can  be  positioned  to 
occupy  rectangular  areas  positioned  above,  below  or 
beside  the  figure. 

16.7.3.2.15        Layout  of  footnote  contents 

A  footnote  body  may  be  placed  at  the  bottom  of  a  body 
area  of  a  page  and  may  or  may  not  be  constrained  to  be 
entirely  in  the  same  body  area  as  the  reference  to  it. 
If  multiple  footnotes  occur  in  the  same  body  area  the 
corresponding  footnote  bodies  can  be  placed  in  the  body 
area  in  the  same  order  as  the  reading  order  of  their 
references. 

16.7.4        Content  characteristics 

A  document  may  contain  any  of  the  following  types  of  content: 

a)  Character  text  utilizing  graphic  characters  as  defined 
in  ISO  6937  and  ISO  8859  together  with  character 
presentation  techniques  defined  in  ISO  8613-6, 

b)  Raster  graphics  images  encoded  according  to  CCITT 
Recommendations  T.4  and  T.6  and  in  unencoded  bitmap 
form, 

c)  Geometric  graphics  images  in  accordance  with  the 
minimum  capabilities  of  ISO  8632,  each  figure 
consisting  of  a  single  picture  only. 

16.7.4.1    Character  content 

The  document  may  contain  character  content  portions  as 
specified  in  ISO  8613-6. 

16.7.4.1.1  Character  repertoire 

The  character  sets  supported  by  this  DAP  include  ISO 
6937-2,   ISO  8859-1  and  ISO  8859-7. 
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The  character  subrepertoires  of  ISO  6937-2  supported  by 
this  DAP  include  the: 

Minimum  subrepertoire  (2) , 
Subrepertoire  of  graphic  character  for 
teletex  (3) , 

Unique  grapics  characters  allocated  to  ISO 
646  (5),  and 

Western  European  data  processing  and 
interchange  or  ISO  8859-1  (8). 


16.7.4.1.2  Character  presentation 

Character  presentation  is  controlled  by  the 
presentation  attributes  specified  in  ISO  8613-6. 

Fonts  may  be  specified  and  selected  at  any  point  in  the 
text.  Up  to  ten  different  fonts  can  be  selected  within 
a  given  portion  of  content. 


16.7.4.1.3  Character  set  features  and 

control  functions 

The  effects  of  graphic  rendition  can  be  changed  at  any 
point  within  the  text  of  a  paragraph. 

Sequences  of  characters  within  a  piece  of  contiguous 
text  may  be  subscripted  or  superscripted. 

Text  can  be  aligned  with  specific  tabulation  stops. 
Text  strings  and  their  justification  can  be  terminated 
by  a  required  newline  and  can  be  word-wrapped  within 
the  paragraph  margins . 

Non-breaking  spaces  and  discretionary  hyphens  are 
supported  in  processable  and  formatted  processable  form 
content. 


16.7.4.2    Raster  graphics  content 

The  document  may  contain  raster  graphics  or  image  content 
portions  as  specified  in  ISO  8613-7. 


16.7.4.3    Geometric  graphics  content 
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The  document  may  contain  geometric  graphics  content  portions 
as  specified  in  ISO  8613-8. 

16.7.5        Miscellaneous  features 


16.7.5.1  Resources 

Structure  components  (generic  or  specific  logical  or  layout) 
as  well  as  content  portions  (character,  raster  or  geometric 

graphics)  of  documents  may  be  located  in  "resource"  document 
external  to  a  particular  document. 

16.7.6        Document  management  features 

A  document  profile  is  associated  with  the  document  to  provide 
information  to  handle  it  as  a  whole. 

The  features  specified  by  the  document  profile  may  contain  those 
document  management  attributes  defined  in  ISO  8613  part  4. 

Document  profile  character  sets  may  use  ISO  6937-2  or  ISO  8859-1. 
16.8  SPECIFICATION  OF  CONSTITUENT  CONSTRAINTS 


16.8.1        Document  profile 

16.8.1.1    Macro  Definitions 


DEFI NE ( CHAR - S ET - LI ST , 


--  ISO 

8859- 

1 

Primary  Set  as  GO  -- 

{2/8  4/2,  LSO)  1 

--  ISO 

8859- 

1 

Supplementary  Set  as 

G2 

{2/14  4/1,  LS2R}  1 

--  ISO 

6937- 

2 

Primary  Set  as  GO  -- 

{2/8  4/0,  LSO}  1 

--  ISO 

6937- 

2 

Supplementary  Set  as 

G2 

{2/14  4/10,  LS2R) 

--  ISO 

8859- 

7 

Supplementary  Set  as 

G2 

{2/14  4/12,  LS2R) 

") 

DEFINE ( NON - BAS IC - PAG - DIM , 

tl 

--  Assured  Reproduction  Areas  -- 

--  Common  North  American  Letter  And  ISO  A4  Landscape  -- 
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#horizontal  <=  12400,  #vertical  <=  9240, 
North  American  Letter  Landscape  -- 
#horizontal  <=  13200,  #vertical  <=  9240, 
North  American  Legal  Portrait  -- 
#horizontal  <=  9240,  #vertical  <=  12400, 
North  American  Legal  Landscape  -- 
#horizontal  <=  12400,  #vertical  <=  9240, 
ANSI  B  Portrait  -- 

#horizontal  <=  12520,  #vertical  <=  19560, 
ANSI  B  Landscape  -- 

#horizontal  <=  19560,  #vertical  <=  12520, 
ISO  A4  Landscape  -- 

#horizontal  <=  13200,  #vertical  <=  9240, 
ISO  A3  Portrait  -- 

#horizontal  <=  13200,  #vertical  <=  18480, 
ISO  A3  Landscape 

#horizontal  <=  18480,  #vertical  <=  13200, 
ISO  A2  Portrait  -- 

#horizontal  <=  18480,  #vertical  <=  26040, 
ISO  Al  Portrait  -- 

#horizontal  <=  26040,  #vertical  <=  36960, 
ISO  AO  Portrait  -- 

#horizontal  <=  36960,  #vertical  <=  52080, 


Full  Page  Sizes  -- 


--  North  American  Letter  Portrait  -- 

#horizontal  <=  10200,  #vertical  <=  13200, 

--  North  American  Letter  Landscape  -- 

#horizontal  <=  13200,  #vertical  <=  10200, 
--  North  American  Legal  Portrait  -- 

#horizontal  <=  10200,  #vertical  <=  16800, 
--  North  American  Legal  Landscape  -- 

#horizontal  <=  16800,  #vertical  <=  10200, 
--  ANSI  B  Portrait  -- 

#horizontal  <=  13200,  #vertical  <=  20400, 
--  ANSI  B  Landscape  -- 

#horizontal  <=  20400,  #vertical  <=  13200, 
--  ISO  A4  Portrait  -- 

#horizontal  <=  9920,  #vertical  <=  14030, 
--  ISO  A4  Landscape  -- 

#horizontal  <=  14030,  #vertical  <=  9920, 
--  ISO  A3  Portrait  -- 

#horizontal  <=  14030,  #vertical  <=  19840, 
--  ISO  A3  Portrait  -- 

#horizontal  <=  19840,  #vertical  <=  14030 


DEFINE(NON-BASIC-NOM-PAG-SIZ, " 

--  North  American  Letter  Landscape  -- 
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#horizontal  <=  13200, 
North  American  Legal 
#horizontal  <=  10200, 
North  American  Legal 
#horizontal  <=  16800, 
ANSI  B  Portrait  -- 
#horizontal  <=  13200, 
ANSI  B  Landscape  -- 
#horizontal  <=  20400, 
ISO  A4  Landscape  -- 
#horizontal  <=  14030, 
ISO  A3  Portrait  -- 
#horizontal  <=  14030, 
ISO  A3  Landscape  -- 
#horizontal  <=  19840, 


#vertical  <= 
Portrait  -- 

#vertical  <= 
Landscape  -  - 

#vertical  <= 

#vertical  <= 
#vertical  <= 
#vertical 
#vertical  <= 
#vertical  <= 


10200, 

16800, 

10200, 

20400, 

13200, 

9920, 

19840, 

14030 


") 


DEFINE (FDA,"  0") 
DEFINE (PDA,"  1") 
DEFINE ( FPDA, "  2") 
DEFINE ( DAC, " 

Document-prof ile {#Document-characteristics 
{#Document-architecture-class ) ) " ) 


DEFINE ( CF, " 

{2  8 

2 

6 

0) 

") 

DEFINE (CP," 

{2  8 

2 

6 

1) 

") 

DEFINE ( CFP, " 

{2  8 

2 

6 

2) 

") 

DEFINE (RFP, " 

[2  8 

2 

7 

2} 

") 

DEFINE(GFP, " 

{2  8 

2 

8 

0} 

") 

DEFINE (PARTIAL, " 

0") 

DEFINE ( COMPLETE, " 

1") 

DEFINE ( PRESENT, " 

1") 

16.8.1.2    Document  profile  constraints 


16.8.1.2.1 


CASE 

$FDA: 
PERM 
REQ 
PERM 

$PDA: 

PERM 

REQ 


Presence  of  document 
constituents 


{($DAC)  OF 


Generic- layout -s true ture 
Specif ic- layout -s true ture 
Presentation- styles 


Generic- layout-structure 
Generic- logical-structure 


{$ COMPLETE) ; 
{$ PRESENT} ; 
{$PRESENT} ; 


{$ COMPLETE} ; 
{$COMPLETE} ; 
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REQ 

PERM 

PERM 

$FPDA: 

REQ 

REQ 

REQ 

REQ 

PERM 

PERM 

) 


Specif ic- logical -structure 
Layout -styles 
Presentation- styles 


Generic- layout-structure 
Specif ic- layout- structure 
Generic -logical -structure 
Specif ic- logical -structure 
Layout- styles 
Presentation- styles 


{$ PRESENT} 
{$ PRESENT) 
{$ PRESENT) 


{$ COMPLETE) ; 
{$PRESENT) ; 
{$ COMPLETE) ; 
{$PRESENT) 
{$ PRESENT) 
{$ PRESENT) 


PERM        External -document -class 
PERM        Resource -document 
PERM  Resources 


(ANY) 
{ANY) 
(ANY) 


16. 8.1. 2.2 


Document  characteristics 


REQ 


REQ 


Document-application-profile     {--  ASN.l  object  identifier  to  be 

supplied  - - ) ; 


Doc-appl -prof ile- defaults 
{  #Document-architecture-defaults 


{($DAC)  OF 


CASE 
$FDA: 

#Content-architecture-class       {$FC) , 
$PDA: 

#Content-architecture-class       {$PC) , 
$FPDA: 

#Content-architecture-class       {$FPC) , 

) 

--  Common  Assured  Reproduction  Area  of  -- 
--  North  American  Letter  Portrait  and  ISO  A4  Portrait 
#Page -dimensions  {9240,  12400), 

--  Nominal  Page  Size  NAL  Portrait,   "unspecified"  -- 
#Medium-type  {10200,13200,0)  ), 


#Character-contents -defaults 
ISO  8859-1  subrepertoire  -- 
#Graphic-char-subrepertoire 


{8)   )  ); 


REQ  Document-architecture-class 

REQ  Content-architecture-class 

REQ  Interchange-format-class 

REQ  ODA- vers ion 


{ANY) ; 
{ANY) ; 
{if-a) ; 

{"ISO  8613,"  "1989-02-08") • 
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REQ         Non-basic-doc-characteristics  { 

{     #Profile-character-sets  { $CHAR- SET-LIST } ; 

#Comment-character-sets  { $CHAR-SET-LIST) ; 

#Alternative- representation- character- sets 

{$CHAR- SET- LIST) ; 

#Dociiment- constituent -at  tributes  { 
{     #Page- dimensions  { $NON-BASIC-PAG-DIM) , 

#Medium-types  { $NON-BASIC-NOM-PAG-SIZ)    }   )  }; 

PERM       Additional-doc-characteristics  { 
{     #Fonts-list  (ANY), 

#Unit-scaling  (ANY)   }  }; 


16.8.1.2.3 


Document  management  attributes 


PERM  Title 

PERM  Subject 

PERM  Document- type 

PERM  Abstract 

PERM  Document -date -and- time 

PERM  Ke3rwords 

PERM  Document -reference 

PERM  Dates-and- times 

PERM  Originators 

PERM  Other-user- information 

PERM  External-references 

PERM  Local- file-references 

PERM  Content-attributes 

PERM  Security- information 


{ANY) 
(ANY) 
(ANY) 
(ANY) 
(ANY) 
(ANY) 
(ANY) 
(ANY) 
{ANY) 
{AI^Y) 
(ANY) 
{ANY) 
{ANY) 
{ANY) 


16.8.2        Logical  Constituent  Constraints 


16.8.2.1    Diagrams  of  Relationships  of  Logical  Constituents 
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Logdoc 
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Ser 
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Title 


Text 


Geometric 


Iter 
Any 


Figure 


Passage 


Raster 


Numbered 
Segment 


Seq 


Paragraph 


U 


Number 


U 


Figure  16.4.     Diagram  of  logical  structure  (1  of  4) 
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ConiinonContent 


Iter 
Any 


Raster 


Geometric 


Text 


PageNumber 


Figure  16.5.     Diagram  of  logical  structure  (2  of  4). 
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Figure  16.6.     Diagram  of  logical  structure  (3  of  4) 
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Text 


Iter 
Any 


Figure 


Y'  Z 


Geometric 


Raster 
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FNote 
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FNBody 
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Y" 
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Y" 


Figure  16.7.     Diagram  of  logical  structure  (4  of  4) 
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16.8.2.2    Macro  definitions 


DEFINE (N, " 
<n> 


DEFINE ( NUMBERS, " 
<numbers> 

DEFINE (NUMBERSTRINGS , 
<numberstrings> 

DEFINE ( PREFIXES, " 
<pref ixes> 

DEFINE (SUFFIXES," 
<suf f ixes> 

DEFINE (SEPARATORS , " 
<separators> 


--any  character  string  from  the  set 
of  characters:   "0,"     "1,"  "9"--  ") 


'number- "<$N>  ") 
'numbers tring-"<$N>  ") 
'prefix- "<$N>  ") 
•  suffix- "<$N>  ") 
'separator- "<$N>  ") 


DEFINE(INITIALISEANY, " 
<binding-pair-constraint>  := 

{ 

<$PREFIXES>,   STRING_LITERAL  |  <$SUFFIXES>,   STRING_LITERAL  | 
<$SEPARATORS>,   STRING_LITERAL  |  <$NUMBERS>,   STRING_LITERAL  | 
<$NUMBERSTRINGS>,   "  " 
)  +  ") 

DEFINE (USENUMBERS , " 
<binding-pair-constraint>  := 

{ 

<$NUMBERS>,INC(B_REF(PREC(CURR_OBJ))   (<$NUMBERS>) )  | 
<$NUMBERSTRINGS>,  <hierarchic-expr>  | 
<s  imp le - expr> 


)  + 


<hierarhic-expr> 


<simple-expr> 


<string-function> 

DEFINE (SEGMENTNUMBER, " 
<string-expr-constraint> 


B_REF ( SUP ( CURR_OBJ ) ) 
(<$NUMBERSTRINGS>)  + 
B_REF ( SUP ( CURR_OBJ ) ) 
(<$SEPARATORS>)  +  <simple-expr) " ) 

<string- function> 

( B_REF ( CURR_OBJ ) ( $NUMBERS ) )  | 

<string-function>  (ORD(CURR_OBJ) )  | 

<STRING-LITERAL> 

MK_STR  I  U_ALPHA  |  L_ALPHA  |  U_ROM 
I  L_ROM  ") 

[<pre-stl>]  <num-stl>  [<suf-stl>] 
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<num-stl> 
<pre-stl> 
<suf-stl> 


DEFINE (PAGENUMBERl , " 
<string-expr-constralnt> 

<pgpre-st2> 
<pgsuf -st2> 
<pgnum-st2> 

<nuine  r  i  c  -  e  xp  r  - 1  > 


<c lass -or- type- 1> 

<c lass -or- type- 2> 

DEFINE (REF,  " 

<string-expr-constraint> 

<pre-st4> 

<suf-st4> 

<nvini-st4> 

<any-object> 


B_REF ( SUP ( CURR_OB J ) ) 
(<$NUMBERSTRINGS>) 
B_REF ( SUP ( CURR_OB J ) ) 
I  STRING_LITERAL 
B_REF ( SUP ( CURR_OB J ) ) 
I   STRING_LITERAL  ") 


(<$PREFIXES>) 
(<$SUFFIXES>) 


[<pgpre-st2>]  <pgniini-st2> 

[<pgsuf-st2>] 

STRING_LITERAL 

STRING_LITERAL 

<string-function> 

(<numeric-expr-l>) 

B_REF ( SUP ( CURR_INST ( 

<class-or-typel>,  CURR_OBJ))) 

($NUMBERS   I   "PGnura")  | 

B_REF(CURR_INST(<class-or-type2>, 

GURR_OBJ))   ($NUMBERS   |  "PGnum") 

frame   |   OBJECT_CLASS_ID_OF( { FrameH 

I  Frame J   |  FrameK}) 

page   I  OBJECT_CLA.SS_ID_OF(Page)  ") 


[<pre-st4>]  <num-st4>  [<suf-st4>] 
B_REF(<any-object>)   (<$PREFIXES>)  | 
STRING_LITERAL 

B_REF(<any-object>)   (<$SUFFIXES>)  | 
STRING_LITERAL 
B_REF ( <any - ob j  e  c  t> ) 
(<$NUMBERSTRINGS>) 
OBJECT_CLASS_ID_OF( { Logdoc  | 
Passage  |  NumberedSegment  |  Number 
I  Title  I  TitleT  |  Paragraph  | 
Phrase   |   PhraseF  |   FNote   |   FNBody  | 
Figure   |  Text  |  Reference   |  Ref  | 
Raster   |  Geometric   |  CommonContent 
I   PageNumber   |  LayDoc   |   PageSet  | 
Page  I  Header  |  Footer  j  BodyFramel 
I  BodyFrame2  j  FrameA  |   FrameB  | 
FrameC  |  FrameD  |  FrameE  |  FrameF  | 
FrameG   j   FrameH  |   Frame I   |   FrameK  | 
Block))  ") 


16.8.2.3    Factor  constraints 
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FACTOR:       ANY-LOGICAL  { 
GENERIC: 

REQ  Object-class-identifier  {ANY}; 
PERM  Resource  (ANY) ; 

SPECIFIC: 

REQ    Object- identifier  (ANY); 
SPECIFIC_AND_GENERIC : 

PERM  Protection  {ANY} 
PERM  User-readable-conunent  {ANY} 
PERM  User-visible-name  {ANY} 
) 

FACTOR:       COMP- LOGICAL       : ANY -LOGICAL  { 
GENERIC: 

REQ    Object-type  { composite- logical-obj ect } ; 

SPECIFIC: 

REQ    Subordinates  {ANY} ; 

PERM  Object-type  {composite-logical-object}; 
SPECIFIC_AND_GENERIC : 

PERM  Layout-style  { STYLE_0F(LStyle3) } ; 

PERM  Default-value- lists  {ANY}; 

} 

FACTOR:       BASIC -LOGICAL     : ANY -LOGICAL  { 
GENERIC: 

REQ    Object-type  {basic-logical-object}; 
SPECIFIC: 

PERM  Object-type  {basic- logical-obj ect } ; 

PERM  Content-portions  {ANY} ; 

) 


16.8.2.4    Logdoc         : ANY- LOGICAL  i 


GENERIC: 

REQ    Object -type 

REQ  Generator-for-subordinates 


SPECIFIC: 


{ document- logical-root } ; 
{ ser(poss (Title) , 
( i  ter ( any ( Paragraph , 
Figure , NumberedSegment , 
Text .Raster .Geometric , 
Passage))) } ; 
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REQ  Object-class 
REQ  Subordinates 
PERM  Object -type 

SPECIFIC_AND_GENERIC : 

PERM  Layout -style 

PERM  Bindings 

PERM  Default-value- lists 

PERM  Application-comments 

) 


{OBJECT_CLASS_ID_OF(Logdoc) } ; 
(ANY) ; 

{ document- logical-root } 


{STYLE_OF(LStylel) } ; 
{$INITIALISEANY} ; 
(ANY) ; 
{"Logdoc") ; 


16.8.2.5    Passage       : COMP-LOGICAL  i 


GENERIC: 

REQ    Generator- for- subordinates 


SPECIFIC: 

REQ  Object-class 

SPECIFIC_AND_GENERIC : 
PERM  Bindings 

PERM  Application-comments 
) 


{ ser(poss(Title) , 
iter (any (Paragraph, 
Figure , NumberedSegment , 
Text , Raster , Geometric , 
Passage) ) ) ) ; 


{ OBJ ECT_CLASS_ID_OF( Pas sage) ) ; 


{$INITIALISEANY 
$USENUMBERS } ; 
{ "Passage" ) ; 


16.8.2.6  NumberedSegment 


COMP: -LOGICAL  i 


GENERIC: 

REQ    Generator-f or-subordinates 


REQ  Bindings 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Bindings 

PERM  Application-comments 
SPECIFIC_AND_GENERIC : 
) 


{seq(Number, { ser(poss (Title) , 

i  ter ( any ( Paragraph , 

Figure , NumberedSegment , 

Text , Raster , Geometric , 

Passage)))))) ; 

{$USENUMBERS} ; 

{ "NumberedSegment" } ; 


{ OBJ  ECT_CLAS  S_I D_0 F ( 
NumberedSegment) ) ; 
{$INITIALISEANY  | 
$USENUMBERS) ; 
{ "NumberedSegment" ) ; 


16.8.2.7  Number 


: BASIC-LOGICAL  1 
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GENERIC: 

REQ    Content- generator 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

PERM  Presentation-style 

PERM  Layout- style 

PERM  Content-architecture-class 

) 


16.8.2.8  Title 

GENERIC : 

REQ  Generator-for-subordinates 


REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

) 


16.8.2.9  TitleT 

GENERIC: 

REQ  Generator-for-subordinates 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

) 


16.8.2.10  Paragraph 

GENERIC: 

REQ  Generator-for-subordinates 

REQ  Application-comments 
SPECIFIC: 


December  '89 


$SEGMENTNUMBER} ; 
"Number" ) ; 


OBJECT_CLASS_ID_OF(Number) ) ; 
"Number" ) ; 


STYLE_OF(PStylel) ) ; 
STYLE_0F(LStyle4) } ; 
$CF  I   $CP   I  $CFP); 


COMP- LOGICAL  i 


{ iter (any (Text ,  Reference, 
Phrase,  FNote,  Figure,  Raster, 
Geometric) ) ) ; 
{ "Title" } ; 


OBJECT_CLASS_ID_OF(Title) } ; 
"Title" ) ; 


COMP -LOGICAL  i 


{ iter (any (Text ,  Reference, 
Phrase,  PhraseF,  FNote))}; 
{ "TitleT" } ; 

{OBJECT_CLASS_ID_OF(TitleT) } ; 
{"TitleT") ; 


COMP -LOGICAL  i 


{ iter (any (Text ,  Reference, 
PhraseF,  Phrase,  FNote, 
Figure,  Raster,  Geometric))); 
{ "Paragraph" ) ; 
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REQ  Object-class 

PERM  Application-comments 
) 


16.8.2.11  Phrase 

GENERIC : 

REQ    Generator- for- subordinates 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

) 


16.8.2. 12  PhraseF 

GENERIC: 

REQ    Generator- for- subordinates 

REQ    Application- comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

} 


16.8.2.13  FNote 

GENERIC: 

REQ  Generator- for- subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ    Object- class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Bindings 


{ OBJECT_CLASS_ID_OF( 
Paragraph) ) ; 
{ "Paragraph" ) ; 


:COMP- LOGICAL  i 


{ iter (any(Text ,  Reference, 
Phrase,  PhraseF,  FNote))}; 
{ "Phrase" } ; 


{ OBJ ECT_CLASS_ID_OF( Phrase) ) ; 
{ "Phrase" ) ; 


:COMP-LOGICAL  i 


{ iter (any (Text ,  Reference, 
PhraseF) ) } ; 
{ "PhraseF" ) ; 


{OBJECT_CLASS_ID_OF(PhraseF) ) ; 
{"PhraseF") ; 


: COM? -LOGICAL  i 


{ser(Number,  FNBody) ) ; 
{ "FNote" } ; 


{OBJECT_CLASS_ID_OF(FNote) ) ; 
{ "FNote" } ; 


{$INITIALISEANY  | 
$USENUMBERS) ; 


16-37 


December  '89 


16.8.2. 14  FNBodv 

GENERIC : 

REQ    Generator -for -subordinates 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

} 


16.8.2.15  Figure 

GENERIC: 

REQ    Generator- for- subordinates 


REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Bindings 

} 


16.8.2.16  Text 

GENERIC: 

REQ  Application-comments 

SPECIFIC: 

REQ    Object- class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

PERM  Content-architecture -class 

PERM  Content-portions 

PERM  Presentation- style 

PERM  Layout- style 

} 


:COMP- LOGICAL  i 


{ser (Number,  Text,  Reference, 
PhraseF} ; 
{"FNBody"} ; 


{OBJECT_CLASS_ID_OF(FNBody) ) ; 
{"FNBody") ; 


:COMP-LOGICAL  i 


{ ser (poss (Number) ,  TitleT, 
iter (any(Text ,  Reference, 
PhraseF,  Phrase,  FNote, 
Raster,  Geometric)))); 
{ "Figure" ) ; 


{OBJECT_CLASS_ID_OF(Figure) ) ; 
{ "Figure" ) ; 


{$INITIALISEANY  | 
$USENUMBERS) ; 


: BASIC-LOGICAL  i 


{ "Text" ) ; 


{ OBJ ECT_CLASS_ID_OF( Text) ) ; 
{ "Text" ) ; 


{$CF  I  $CP  I  $CFP); 
{ANY) ; 

{STYLE_0F(PStyle2) ) ; 
{STYLE_0F(LStyle5) ) ; 


16.8.2. 17  Reference  : COMP- LOGICAL  i 
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GENERIC: 

REQ    Generator- for- subordinates 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Bindings 

) 


16.8.2.18  Ref 


GENERIC: 

REQ  Application-comments 

SPECIFIC: 

REQ    Object- class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

PERM  Content -generator 

PERM  Content-portions 

PERM  Content-architecture-class 

PERM  Presentation-style 

PERM  Layout- style 

) 

16.8.2.19  Raster 

GENERIC: 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

PEEIM  Content-architecture-class 

PERM  Content-portions 

PERM  Presentation-style 

PER^I  Layout- style 

) 


{ ser (poss (Text) ,  Ref, 
poss(Text) ) ) ; 
{ "Reference" ) ; 

{ OBJ  ECT_CLAS  S_ID_OF ( 
Reference) ) ; 
{ "Reference" } ; 

{$INITIALISEANY  | 
$USENUMBERS) ; 


: BASIC-LOGICAL  i 


{ "Ref" } ; 


{OBJECT_CLASS_ID_OF(Ref) } ; 
{"Ref") ; 


{$REF) ; 
(ANY) ; 

{$CP  1  $CFP}; 
{STYLE_0F(PStyle2) ) ; 
{STYLE_0F(LStyle5) } ; 


: BASIC-LOGICAL  i 
{ "Raster" ) ; 


{OBJECT_CLASS_ID_OF(Raster) ) ; 
{"Raster") ; 


{$RFP}; 
{ANY) ; 

{STYLE_0F(PStyle3) ) ; 
{STYLE_0F(LStyle6) ) ; 


16.8.2.20  Geometric  : BASIC-LOGICAL  1 
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GENERIC: 

REQ    Application-comments  {"Geometric"); 
SPECIFIC: 

REQ    Object-class  { OBJECT_CLASS_ID_OF( 

Geometric) ) ; 

PERM  Application-comments  {"Geometric"); 
SPECIFIC_AND_GENERIC : 

PERM  Content-architecture-class  {$GFP); 

PERM  Content-portions  {ANY}; 

PERM  Presentation-style  { STYLE_0F(PStyle4) ) ; 

PERM  Layout-style  { STYLE_0F(LStyle6) ) ; 

) 


16.8.2.21  CommonContent 


i 


GENERIC:  ■  ; 

REQ    Object -type 
REQ  Object-class-identifier 
REQ  Generator-for-subordinates 

REQ    Application- comments 
PERM  Resource 

PERM  User -readable -comments 

PERM  User-visible-name 

PERM  Protection 

PERM  Default-value- list  ' 

} 


{ composite- logical-obj ect } ; 
{ANY) ; 

{ iter (any (Raster ,  Geometric, 
Text,   PageNumber) ) ) ; 
{ "CommonContent" ) ; 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
(ANY) 


16.8.2.22  PageNumber 

GENERIC: 

REQ    Object- type 
REQ  Object-class-identifier 
REQ    Content- generator 
PERM  Resource 
PERM  Presentation-style 
PERM  Content-architecture-class 
PERM  User-readable-comments 
PERM  User-visible-name 
PERM  Protection 
PERM  Layout- style 
PERM  Application-comments 
} 


{basic- logical-obj ect ) ; 
{ANY) ; 

{$PAGENUMBER1 ) ; 
{ANY) ; 

{STYLE_0F(PStyle2) ) ; 
{$CP) 
{ANY) 
{ANY) 
{ANY) 

{STYLE_0F(LStyle2) ) ; 
{ "PageNumber" ) ; 
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16.8.3        Layout  Constituent  Constraints 


16.8.3.1     Diagrams  of  Relationships  of  Layout 
Constituents 


Poss 


Page 


Rep 


Page 


Laydoc 


Iter 


PageSet 


Ser 
Any 


Poss 


VPage 


RPage 

VPage 

X 

X 

Seq 


Poss 


Poss 

Rep 

Seq 


RPage 


Figure  16.8.     Diagram  of  Layout  Structure  (1  of  4). 
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Figure  16.9.     Diagram  of  Layout  Structure  (2  of  4). 
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Figure  16.10.     Diagram  of  Layout  Structure  (3  of  4) 
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v:  Variable  position 


Figure  16.11.     Diagram  of  Layout  Structure  (4  of  4). 
16.8.3.2    Macro  definitions 


DEFINE (PAGENUMBER- 2 , " 
<string-expr-constraint>  := 

<numeric- express ion- 2>  := 


<string-function> 
(<numeric- express ion- 2>) 
B_REF(  SUP_OBJ(  CURR_INST(  frame, 
CURR_OBJ ) ) ) ( " PGnum" )  " ) 


DEFINE(PAGE-DIMENSIONS,  " 

--  Common  Assured  Reproduction  Area  of  -- 

--  North  American  Letter  and  ISO  A4  Portrait  -- 

#horizontal  <=  9240,  #vertical  <=  12400  ( 
--  Assured  Reproduction  Area  of  -- 
--  North  American  Letter  Portrait  -- 

#horizontal  <=  9240,  #vertical  <=  12400  \ 
--  Assured  Reproduction  Area  of  ISO  A4  Portrait  -- 
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#horizontal  <=  9240,  #vertical  <=  13200  ") 
DEFINE(NOMINAL-PAGE-SIZE,  " 
--  North  American  Letter  Portrait  -- 

#horizontal  <=  10200,  #vertical  <=  13200  | 
--  ISO  A4  Portrait  -- 

#horizontal  <=  9920,  #vertical  <=  14030  ") 


16.8.3.3     Factor  constraints 


FACTOR:       ANY -LAYOUT  { 
GENERIC: 

REQ  Object-class 
SPECIFIC: 

REQ    Object- identifier 

SPECIFIC_AND_GENERIC : 
PERM  User-visible-name 
PEIiM  User-readable-comment 
) 

FACTOR:  ANY- PAGE  : ANY- LAYOUT 
GENERIC: 

REQ    Object -type 

REQ    Generator -for -subordinates 


PERM  Resource 

SPECIFIC: 

REQ  Subordinates 

PEEIM  Object -type 

SPECIFIC_AND_GENERIC : 

PERM  Dimensions 

PERM  Transparency 

PERM  Colour 

PERM  Page-position 

PERM  Bindings 

) 


(ANY) ; 
{ANY) ; 


(ANY) ; 
(ANY); 


{page} ; 

{ set (any (opt (FrameJ) , 
poss (Header) ) , 
any (opt (FrameK) , 
poss (BodyFramel ) , 
poss (BodyFrame2) ) , 
any (opt (FrameJ) , 
poss (Footer) ) ) ) ; 
{ANY} ; 


{ANY) ; 
{page} ; 


{$PAGE-DIMENSIONS 
{ANY) 
{AfJY) 
{ANY) 

{ MAN I PULAT I ON ( PGnum ) 


FACTOR: 


ANY- FRAME  : ANY- LAYOUT 
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GENERIC : 

REQ    Object -type 

SPECIFIC: 

PERM  Object -type 

) 


16.8.3.4  Lavdoc 

GENERIC : 

REQ    Object- type 

REQ    Generator- for- subordinates 

PERM  Resource 

SPECIFIC: 
REQ  Object-class 
REQ  Subordinates 
PERM  Object -type 

SPECIFIC_AND_GENERIC : 

PERM  Default-value- lists 

PERM  Bindings 

PERM  Application-comments 

} 


16.8.3.5  PageSet 

GENERIC: 

REQ    Object -type 

REQ    Generator- for- subordinates 


PERM  Resource 

SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 
PERM  Object -type 

SPECIFIC_AND_GENERIC : 

PERM  Bindings 

PERM  Application-comments 


{ frame ) ; 
{ frame ) ; 


: ANY- LAYOUT  i 


{document-layout-root) ; 
{ iter (pageset) ) ; 
(ANY) ; 


{OBJECT_CLASS_ID_OF(Laydoc) ) ; 
(ANY) ; 

{ document- layout -root ) ; 


(ANY) ; 

{ Initialization(PGnum) ) ; 
{"Laydoc"} ; 


: ANY -LAYOUT  i 


(pageset) ; 

{ ser (poss (Page) , 

any (rep (Page) , 

seq(poss (RPage) ,  poss  rep 

seq(VPage,  RPage), 

poss(VPage))))) ; 

(ANY); 


{OBJECT_CLASS_ID_OF(PageSet) }  ; 

(ANY); 
(pageset) ; 


( Initialization(PGnum) ) ; 
( "PageSet" ) ; 
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16.8.3.6     Page   : ANY- PAGE  1 

SPECIFIC: 
REQ  Object-class 

SPECIFIC_AND_GENERIC : 
PERM  Medium- type 

#Nomlnal -page -size 

#Side-of-sheet 
PERM  Application-comments 
) 


{ OBJ ECT_CLASS_ID_OF( Page) } 


{ 

{$NOMINAL-PAGE-SIZE) , 
{"unspecified")  ); 
{"Page") ; 


16.8.3.7  RPape 

SPECIFIC: 

REQ  Object-class 

SPECIFIC_AND_GENERIC : 
PERM  Medium- type 

#Nominal -page - s  ize 

#Side-of-sheet 
PERM  Application-comments 


: ANY- PAGE  i 


{OBJECT_CLASS_ID_OF(RPage) } ; 


( 

{$NOMINAL- PAGE- SIZE) , 
{"recto")  ); 
{ "RPage" ) ; 


16.8.3.8  VPage 

SPECIFIC: 

REQ    Object- class 

SPECIFIC_AND_GENERIC : 
PERM  Medium- type 

#Nominal -page -size 

#Side-of -sheet 
PERM  Application-comments 


: ANY- PAGE  i 


{OBJECT_CLASS_ID_OF(VPage) ) ; 


{ 

{$NOMINAL- PAGE- SIZE) , 
{"verso")  ); 
{ "VPage" ) ; 


16.8.3.9    Header        :ANY-FRAME  1 


GENERIC : 

REQ  Generator-for-subordinates 

REQ  Position 
REQ  Dimensions 

REQ    Application- comments 
PERM  Resource 


{any(iter(any(FrameC , FrameH) ) , 
iter (any (FrameH , FrameG) ) ) ) ; 
{#fixed{ANY) ) ; 
{#horizontal{#f ixed{ANY} ) , 
#vertical{#f ixed{ANY} ) ) ; 
{ "Header") ; 
(ANY) ; 
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SPECIFIC: 

REQ    Object- class 

REQ  Subordinates 

PERM  Imaging- order 

PERM  Application-comments 


{OBJECT_CLASS_ID_OF(Header) } ; 

{ANY} ; 

{ANY} ; 

{ "Header" } ; 


SPECIFIC_AND_GENERIC : 

PERM  Transparency  {ANY} ; 

PERM  Colour  {ANY} ; 

PERM  Border  {ANY} ; 

PERM  Layout -path  {90  |  270}; 
) 


16.8.3. 10  Footer        :ANY-FRAME  i 


GENERIC: 

REQ  Generator-for-subordinates 

REQ  Position 

REQ  Dimensions 

REQ  Application-comments 

PERM  Resource 

SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Position 

PERM  Dimensions 

PERM  Imaging-order 

PERM  Application-comments 


{ any(iter(any(FrameC , FrameH) ) , 

iter(any(FrameH, FrameG) ) ) } ; 

{#fixed{ANY) } ; 

{ANY} ; 

{"Footer"}; 

{ANY} ; 


{OBJECT_CLASS_ID_OF(Footer) } ; 
{ANY} ; 
{ANY} ; 

{#fixed{ANY) } ; 

{ANY} ; 

{ "Footer" } ; 


SPECIFIC_AND_GENERIC : 
PERM  Transparency 
PERM  Colour 
PERM  Border 
PERM  Layout -path 
) 


{ANY] 
{ANYl 
{ANY] 
{90  I 


270) 


16.8.3.11  BodvFramel 


: ANY- FRAME 


1 


GENERIC: 

REQ    Generator-for-subordinates        { iter (any (FrameB , FrameC , 

FrameD , FrameF , FrameH) ) } ; 

REQ    Position  {#fixed{ANY) } ; 

REQ    Dimensions  {#horizontal {#f ixed{ ANY) } , 

#vertical{#fixed{ANY} } } ; 

REQ    Application-comments  { "BodyFramel " } ; 

PERM  Resource  (ANY) ; 
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SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Position 

PERM  Dimensions 

PEEIM  Imaging-order 

PERM  Application- comments 

SPECIFIC_AND_GENERIC : 
PERM  Transparency 
PERM  Colour 
PERM  Border 
PERM  Layout -path 
) 


{ OBJECT_CLASS_ID_OF 
( Body Frame  1 ) ) ; 
(ANY) 
(ANY) 
{ANY} 
(ANY) 

{ "BodyFramel" ) ; 


(ANY) 
(ANY) 
(ANY) 
(90  I  270) 


16.8.3. 12  BodyFrame2 


: ANY-FRAME 


GENERIC: 

REQ    Generator- for- subordinates 

REQ  Position 
REQ  Dimensions 

REQ  Application-comments 
PERM  Resource 


{ seq(iter(any(FrameA,  FrameH, 
FrameG ,  Body Frame 1 ) ) ) ) ; 
{#fixed{ANY) ) ; 
{#horizontal{#fixed{ANY} ) , 
#vertical{#fixed{ANY) ) ) ; 
{ "Body Frame 2" ) ; 
{ANY} ; 


SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Position 

PERM  Dimensions 

PERM  Imaging-order 

PERM  Application-comments 


{ OBJECT_CLASS_ID_OF 
(BodyFrame2) ) ; 
{ANY} 
{ANY} 
{ANY} 
{ANY} 

{"BodyFrame2") ; 


SPECIFIC_AND_GENERIC : 
PERM  Transparency 
PERM  Colour 
PERM  Border 
PERM  Layout -path 
} 


{ANY) 
{ANY) 
{ANY) 
{90  I  270); 
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16.8.3. 13  FrameA         : ANY- FRAME  1 


GENERIC: 

REQ  Position 

REQ  Dimensions 


REQ  Application-comments 

SPECIFIC: 

REQ    Object -class 

REQ  Subordinates 

PERM  Position 

PERM.  Dimensions 

PEEIM  Imaging- order 

PERM  Application- comments 

SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories 

PERM  Transparency 

PERM  Colour 

PERM  Border 

) 


16.8.3.14  FrameB 

GENERIC: 

REQ    Generator- for- subordinates 

REQ  Position 
REQ  Dimensions 

REQ    Application- comments 

SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Position 

PERM  Dimensions 

PERM  Imaging-order 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Permitted-categories 
PERM  Transparency 
PERM  Colour 
PERM  Border 
PERM  Layout -path 


{#fixed{ANY)  | 
#variable{ANY) } ; 
{#horizontal{ANY) , 
#vertical{ANY}  j 
#horizontal { fixed,  default), 
#vertical(RuleB) ) ; 
{"FrameA") ; 

{ OBJ ECT_CLASS_ID_OF( FrameA) ) ; 

{ OBJ ECT_ID_OF( Block) ) ; 

(ANY) ; 

(ANY) ; 

(ANY) ; 

{"FrameA"); 


{ANY) 
{ANY) 
{ANY) 
{ANY) 


: ANY- FRAME  i 


{ any ( iter (FrameA) , 
iter(any(FrameA, Framel) ) ) ) ; 
(#variable{ANY) ) ; 
{#horizontal{ fixed {ANY) , 
default ) ,  #vertical { RuleB ) ) ; 
{"FrameB") ; 


{OBJECT_CLASS_ID_OF(FrameB) ) ; 

{OBJECT_ID_OF(Block) ) ; 

{ANY} ; 

{ANY) ; 

{ANY) ; 

{ "FrameB" ) ; 


{ANY) ; 
{ANY) ; 
{ANY) ; 
{ANY) ; 

{0|  90|  270); 
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PERM  Balance  (ANY] 
) 


16.8.3.15  FrameC 

GENERIC: 

REQ  Position 

REQ  Dimensions 

REQ  Application-comments 

PERM  Resource 

SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Position 

PERM  Dimensions 

PERM  Imaging-order 

PERK  Application-comments 

SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories 

PERM  Transparency 

PERM  Colour 

PEEIM  Border 


: ANY- FRAME  1 


{#variable{ANY) } ; 
(#horizontal{ fixed (ANY) , 
default),   #vertical (RuieB) ) ; 
{"FrameC") ; 
(ANY) ; 

{OBJECT_CLASS_ID_OF(FrameC) ) ; 
{OBJECT_ID_OF(Block) ) ; 
(ANY) ; 

{ #horizontal { default ) , 
#vertical{ANY} ) ; 
(ANY) ; 
{"FrameC") ; 

{ANY) ; 
(ANY) ; 
(ANY) ; 
(ANY) ; 


16.8. 3. 16  FrameD 

GENERIC: 

REQ    Generator- for- subordinates 

REQ  Position 
REQ  Dimensions 

REQ    Layout -path 

REQ  Application-comments 

PERM  Resource 

SPECIFIC: 
REQ  Object-class 
REQ  Subordinates 
PEEIM  Position 
PERM  Dimensions 

PEIiM  Imaging-order 

PERM  Application-comments 


: ANY- FRAME  i 


{ any( iter (FrameE) , 
iter(FrameG) ) ) ; 
{#variable{ANY) ) ; 
{#horizontal{default} , 
#vertical (RuleA) ) ; 
(0   I  180); 
{ "FrameD" ) ; 
(ANY) ; 


{ OBJ ECT_CLASS_ID_OF( FrameD) ) ; 
{ANY} ; 
(ANY) ; 

{#horizontal{ default) , 
#vertical{ANY} ) ; 
(ANY) ; 
{ "FrameD" ) ; 
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SPECIFIC_AND_GENERIC : 

PERM  Transparency 

PERM  Colour 

PERM  Border 

PERM  Bindings 

) 


{ANY} 
(ANY) 
(ANY) 

{MANIPULATION(PGnum) ) ; 


16.8.3.17  Frame E 

GENERIC: 

REQ  Position 

REQ    D  imens  i  ons 

REQ  Application-comments 
PERM  Resource 

SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Position 

PERM  Dimensions 

PERM  Iraaging-order 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

REQ  Permitted-categories 

PERM  Transparency 

PERM  Colour 

PERM  Border 

) 


16.8.3.18  FrameF 

GENERIC: 

REQ  Position 


REQ  Dimensions 

REQ  Application-comments 
PERM  Resource 

SPECIFIC: 
REQ  Object-class 
REQ  Subordinates 
PERM  Position 


: ANY- FRAME  i 


{#variable{ANY) ) ; 
{#horizontal{RuleB,  fixed, 
default ) ,  #vertical { RuleB ) ) ; 
{"FrameE"} ; 
(ANY); 


(OBJECT_CLASS_ID_OF(FrameE) } ; 
{OBJECT_ID_OF( Block) ) ; 
(ANY) ; 
{ANY} ; 
{ANY} ; 
{"FrameE"} ; 


{ANY} 
{ANY} 
{ANY} 
{ANY} 


: ANY- FRAME  i 


{#variable{ 

#fillorder{reversed} ) , 
#offset{ANY} , 
#separation{ANY) , 
#alignment{ANY} ) ; 
{#horizontal{ default} , 
#vertical{ RuleB} } ; 
{ "FrameF" } ; 
{ANY); 


{OBJECT_CLASS_ID_OF( FrameF) ) ; 
{OBJECT_ID_OF(Block) ) ; 
{ANY} ; 
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PERM  Dimensions 

PERM  Imaging- order 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

REQ  Permitted-categories 

PERM  Transparency 

PERM  Colour 

PERM  Border 

) 


16.8.3. 19  FrameG 

GENERIC: 

REQ  Position 

REQ  Dimensions 

REQ  Application-comments 

PERM  Generator- for- subordinates 

PERM  Resource 

SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Position 

PERM  Dimensions 

PERM  Imaging- order 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

PERM  Permitted-categories 

PERM  Transparency 

PEIiM  Colour 

PERM  Border 

) 


16.8.3.20  FrameH 

GENERIC: 

REQ  Position 

REQ  Dimensions 

REQ    Logical -source 

REQ  Application-comments 

PERM  Generator- for- subordinates 

PERM  Resource 


{#horizontal { default ) , 
#vertical{ANY) ) ; 
{ANY) ; 
{"FrameF" } ; 


(ANY) 
(ANY) 
{ANY} 
{ANY} 


: ANY- FRAME  1 


{#fixed{ANY} } ; 
{#horizontal{ANY} , 
#vertical{ANY} } ; 
{ "FrameG" ) ; 
{ seq { Block} } ; 
{ANY} ; 

{ OBJ ECT_CLASS_ID_OF( FrameG) ) ; 

{OBJECT_ID_OF(Block) ) ; 

{ANY) ; 

{ANY) ; 

{ANY} ; 

{ "FrameG" ) ; 


{ANY) 
{ANY) 
{ANY) 
{ANY) 


: ANY- FRAME  1 


{#fixed{ANY}  | 
#variable{ANY} } ; 
{#horizontal { default } , 
#vertical{RuleB) ) ; 
{OBJECT_CLASS_ID_OF( 
CommonContent) ) ; 
{"FrameH") ; 
{ iter(Block) } ; 
{ANY} ; 
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SPECIFIC: 
REQ    Object- class 
REQ  Subordinates 
PERM  Position 
PERM  Dimensions 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Border 
PERM  Layout -path 
) 

16.8.3.21  Framel 

GENERIC: 

REQ    Generator-f or-subordinates 


REQ  Position 
REQ  Dimensions 

REQ  Application-comments 
PERM  Resource 

SPECIFIC: 

REQ    Object- class 

REQ  Subordinates 

PERM  Position 

PEEIM  Dimensions 

?ERK  Imaging- order 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout -path 
PERM  Transparency 
PERM  Colour 
PERM  Border 


{OBJECT_CLASS_ID_OF(FrameH) } ; 
{OBJECT_ID_OF(Block) ) ; 
{ANY} ; 

{#horizontal{ default) , 
#vertical{ANY} ) ; 
{"Frame"); 


{ANY); 
{ANY) ; 


:ANY-FRAME  i 


{ any ( iter (any (FrameC , 
FrameD.FrameF)) , 
iter(FrameG) ) ) ; 
{#fixed{ANY) | #variable { ANY) ; 
{ #hor izontal { fixed ,  default } , 
#vertical{RuleB) } ; 
{"Framel"); 
{ANY) ; 


{OBJECT_CLASS_ID_OF(FrameI) ) ; 

{ANY); 

(ANY) ; 

{ANY) ; 

{ANY) ; 

{ "Framel" ) ; 


{90  I  270); 
{ANY) ; 
{ANY) ; 
{ANY) ; 


16.8.3.22  FrameJ 

GENERIC: 

REQ    Logical -source 
PERM  Position 
PERM  Dimensions 

SPECIFIC: 

REQ    Object- class 


: ANY- FRAME  1 
{ANY) ; 

{#fixed{ANY) ) ; 
{#fixed{ANY) ) ; 

{ OBJ ECT_CLASS_ID_OF( FrameJ) ) ; 
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REQ  Subordinates 
PERM  Position 
PERM  Dimensions 
PERM  Layout -path 

SPECIFIC_AND_GENERIC : 
PERM  Application-comments 
} 


{OBJECT_ID_OF( Block) ) ; 
(ANY) ; 

{#fixed{ANY) ) ; 
(270) ; 


{ "FrameJ") ; 


16.8.3.23  FrameK 

GENERIC: 
PERM  Position 

SPECIFIC: 
REQ  Object-class 
REQ  Subordinates 
PERM  Position 
PERM  Layout -path 

SPECIFIC_AND_GENERIC : 

PERM  Dimensions 

PERM  Application- comments 

) 

16.8.3.24  Block 

GENERIC : 

REQ    Object- type 

REQ  Content-architecture-class 

PERM  Content-generator 

REQ    Application- comments 

PERM  Resource 

SPECIFIC: 

REQ  Content-architecture-class 
PERM  object -type 
PERM  Position 
PERM  Dimensions 

PERM  Initial-offset 
PERM  Formatting- indicator 
PERM  Graphic -rendition 
PERM  Graphic-character-set 
PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Content-portions 
PERM  Transparency 
PERM  Colour 


: ANY- FRAME  i 


{#fixed{ANY} } ; 


{OBJECT_CLASS_ID_OF( FrameK) ) ; 
{OBJECT_ID_OF(Block) ) ; 
(ANY) ; 
{270}; 


{#fixed{ANY) ) ; 
{"FrameK") ; 


: ANY -LAYOUT  1 

(block) ; 
(ANY) ; 

{$PAGENUMBER-2) ; 
{"Block") ; 
(ANY) ; 


(ANY) ; 

{Block) ; 

{#fixed{ANY) ) ; 

{#horizontal{#f ixed{ANY) ) , 

#vertical{#fixed{ANY) ) ) ; 

(ANY) ; 

{ANY) ; 

{ANY) ; 

(ANY) ; 

{ "Block" ) ; 


(ANY) ; 
(ANY) ; 
(ANY) ; 
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PERM  Border 

PERM  Presentation-style 


) 


(ANY) ; 

{STYLE_ID_OF(PStylel  |  PStyle2 
I  PStyleS   I  PStyle4}; 


16.8.4        Layout  style  constraints 

16.8.4.1  Factors 
FACTOR  ANY -LAYOUT -STYLE  { 


REQ    Layout-style- identifier 
PERM  User-visible-name 
PERM  User-readable-comments 
} 


{ANY} 
(ANY) 
{ANY} 


16.8.4.2  LStvlel 


REQ  Layout- obj ect-class 
) 


: ANY -LAYOUT -STYLE  i 
{OBJECT_CLASS_ID_OF(Laydoc) } ; 


16.8.4.3     LStvle2       : ANY -LAYOUT -STYLE  i 


PERM  Block-alignment 
PERM  Concatenation 
PERM  Indivisibility 
PERM  Layout -category 
PERM  Layout-object-class 
PERM  New- layout-object 
PEEIM  Same- layout-object 
PERM  Offset 
PERM  Separation 
) 


{ANY} 
{ANY} 
{ANY} 
{ANY} 
{ANY} 
{ANY} 
{ANY} 
{ANY} 
{ANY} 


16.8.4.4    LStvleS       : ANY -LAYOUT -STYLE  i 


PERM  Indivisibility 
PERM  Layout-object-class 
PERM  New- layout-obj ect 
PERM  Same- layout-obj ect 
PERM  Synchronization 
} 


{ANY} 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
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16.8.4.5     LStvIe4       : ANY -LAYOUT -STYLE  1 


PERM  Block-alignment 
PERM  Concatenation 
PERM  Indivisibility 
PEEIM  Layout-category 
PERM  Layout-object- class 
PERM  New- layout-object 
PERM  Same -layout -object 
PERM  Offset 
PERM  Separation 
PERM  Synchronisation 
) 


(ANY) 
(ANY) 
(ANY) 
{ANY} 
(ANY) 
(ANY) 
(ANY) 
(ANY) 
{ANY) 
{ANY) 


16.8.4.6    LStvleS       : ANY- LAYOUT -STYLE  1 


PERM  Block- alignment 
PERM  Concatenation 
PERM  Indivisibility 
PERM  Layout-category 
PERM  Layout-object-class 
PERM  New- layout -object 
PERM  Same -layout -object 
PERM  Offset 
PERM  Separation 
PERM  Synchronisation 
PERM  Fill -order 
} 


(ANY) 
(ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 


16.8.4.7    LStvle6       : ANY -LAYOUT -STYLE  i 


PERM  Block-alignment 
PERM  Indivisibility 
PERM  Layout -category 
PERM  Layout - ob j ect- class 
PERM  New- layout -object 
PERM  Same -layout -object 
PERM  Offset 
PERM  Separation 
PERM  Synchronisation 
) 


{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
{ANY) 
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16.8.5        Presentation  style  constraints 


16.8.5.1  Macros 


DEFINE (C-PRES-ATTR, " 

PERM  Alignment 

PERM  Character- fonts 

PERM  Character-orientation 

PERM  Character-path 

PERM  Character-spacing 

PERM  Code -extension- announcer 

PERM  First-line-offset 

PERM  Formatting- indicator 

PERM  Graphic-character-sets 

PERM  Character- subrepertoire 


PERM 

Graphics -rendition 

{ANY} 

PERM 

Indentation 

{ANY} 

PERM 

Initial-offset 

{ANY} 

PERM 

Itemization 

{ANY} 

PERM 

Kerning-of f set 

{ANY} 

PERM 

Line- layout- table 

{ANY} 

PERM 

Line -progress ion 

{ANY} 

PERM 

Line -spacing 

{100 

150 

PERM 

Orphan- size 

{ANY} 

PERM 

Pairwise -kerning 

{ANY} 

PERM 

Proportional- line-spacing 

{ANY} 

PERM 

Widow-size 

{ANY} 

") 

DEFINE (R- PRES - ATTR , " 

PERM 

Pel-path 

{ANY} 

PERM 

Line -progress ion 

{ANY} 

PERM 

Pel-spacing 

{75  1 

100 

300  1 

400 

PERM 

Spacing-ratio 

{ANY) 

PERM 

Clipping 

{ANY} 

PERM 

Image - dimens  ions 

{ANY) 

") 

ANY) 
ANY) 
ANY) 
ANY) 
ANY) 
ANY) 
ANY) 
ANY) 

$CHAR-SET-LIST) ; 

2  --  Minimal  -- 

3  --  Teletex  -- 
5  --  ISO  646  -- 

8  --  ISO  8859-1  - 


); 


I  200  I  300  I  400); 


400  I   600  I  1200); 


DEFINE(G-PRES-ATTR, " 

PERM  Geometric -graphics -encoding- announcer 
{ 


#VDC-type 
#Integer -precis ion 
#Real -precis ion 
#Index-precision 
#Colour -precis ion 
#Colour- index-precision 
#Maximum- CO lour- index 


{ANY) 


{16 
{{0 
{8  I 
{8  I 


I  32) 
9  23) 
16}  , 
16), 
{8  I  16), 
(ANY) , 


I    {1  16  16)), 
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PERM 
PERM 
PERM 
{ 


PERM 
{ 


#Co lour -value -extent 
#Colour- selection-mode 
#VDC- integer-precision 
#VDC- real -precis ion 
Line -rendition 
Marker - r endi  t  ion 
Text-rendition 

#Font-list 

#Character- set- list 

#Character- coding- announcer 

#Text -bundle- index 

#Tex t -  font -  index 

#Text -precis ion 

#Character-expansion- factor 

#Charac  ter - spac  ing 

#Text-colour 

#Charac ter -height 

#Charac ter -orientation 

#Text-path 

#Text- alignment 

#Character- set- index 

#Text-asf 

#Text -bundle -representation 
Filled- area- rendition 


(ANY) 
(ANY) : 
{16  I 
{{0  9 
{ANY} : 
{ANY) ; 


32}  , 

23}  ' I   (1  16  16) )  } 


{ANY) , 

{$CHAR-SET-LIST) , 

{basic-7-bit  |  basic 

{ANY) . 

{ANY) , 

{ANY) , 

{ANY) , 

{ANY) , 

{ANY) , 

{ANY) , 

{ANY) , 

{ANY) , 

{ANY) , 

{ANY) , 

{ANY) 

{ANY)  ); 


■bit)  , 


#Fill-bundle- index 

{ANY) , 

#Interior- style 

{ANY) , 

#Fill-colour 

{ANY) , 

#Hatch- index 

{ANY) , 

#Pattern- index 

{1  .. 

8}  , 

#Fill- reference -point 

{ANY) , 

#Pattern-size 

{ANY) , 

#Pattern- table -representation 

{        #Pattern- table- index 

{1  .. 

8), 

#Numb e r - o f - c o 1 umns 

{1  .. 

16)  , 

#Number-of -rows 

{1  .. 

16)  , 

#Local- CO lour -precis ion 

{0   1  1 

1  8 

#Colour-arry 

{ANY} 

}  , 

#Fill-asf 

(ANY) 

); 

PERM 

Edge -rendition 

{ANY} , 

PERM 

Co lour -representation 

(ANY) ; 

PERM 

Transparency- specif ication 

(ANY) ; 

PERM 

Trans format ion- specification 

(ANY) ; 

PERM 

Region-of-interest-specif ication  {ANY) ; 

PERM 

Picture -orientation 

{ANY} ; 

PERM 

Picture -dimensions 

{ANY} ; 

") 

I  16), 
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16.8.5.2  Factors 

FACTOR:       ANY- PRESENTATION- STYLE  { 

REQ    Presentation-style- identifier  (ANY) 


PERM  User-readable-comments 

PERM  User-visible-name 

PERM  Border 

PERM  Colour 

PERM  Transparency 

) 


(ANY) 
(ANY) 
(ANY) 
{ANY} 
{ANY} 


16.8.5.3    PStvlel       : ANY - PRE  S  ENTAT I ON - S TYLE  i 


PEEIM  Presentation-Attributes 
) 


{$C-PRES-ATTR} ; 


16.8.5.4    PStvle2       : ANY- PRESENTATION- STYLE  i 


CASE  ( Document -prof ile (Document -character is tics 
#Content-archicture-class) )  OF 

$FDA: 

REQ  Content-architecture-class 
$PDA: 

REQ  Content-architecture-class 
$FPDA: 

REQ  Content-architecture-class 
--  ENDCASE  -- 

PERM  Presentation-attributes 
) 


{$CF}; 
{$CP} ; 
{$CFP} ; 

{$C-PRES-ATTR} ; 


16.8.5.5     PStyle3       : ANY- PRESENTATION- STYLE  i 


REQ  Content-architecture-class 
PERM  Presentation-attributes 
} 


{$RFP} ; 

{$R-PRES-ATTR} ; 


16.8.5.6    PStvle4       : ANY- PRESENTATION- STYLE  i 


REQ    Content-architecture -class 
PERM  Presentation-attributes 
) 


{$GFP} ; 

{$G-PRES-ATTR} ; 
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16.8.6        Content  portion  constraints 


16.8.6.1     Character  content  portion 
SPECIFIC_AND_GENERIC : 

PERM  Content- identifier- layout  (ANY); 

PERM  Content-identifier-logical  {ANY); 

REQ    Type -of- coding  {28360}; 

PERM  Alternative -representation        {ANY) ; 

PERM  Content- information  { 

{        #Character  {ANY), 

--  Shared  Control  Functions  -- 

#CR  {  )  , 

#GCC  {ANY), 

#IGS  {ANY), 

#LF  {  )  , 

#PLD  { } , 

#PLU  {  )  , 

#SCS  (ANY), 

#SGR  (ANY), 

#SHS  {0  I   1   I   2   I  3), 

#SLS  (ANY) , 

#SRS  {ANY) , 

#STAB  {ANY) , 

#SUB  { ) , 

#SVS  (ANY), 

#VPB  (ANY), 

#VPR  (ANY) , 

--  Layout  Control  Functions  -- 

#HPB  (ANY), 

#HPR  (ANY) , 

#JFY  (ANY), 

#SACS  (ANY) , 

#SRCS  (ANY) , 

#SSW  (ANY), 

--  Logical  Control  Functions  -- 

#BPH  { ) , 

#NBH  (  )  , 

#PTX  (ANY), 

--  Delimiter  Functions  -- 

#SOS  { ) , 

#SP  (}, 

#ST  { )  ) ; 


16.8.6.2    Raster  graphics  content  portion 
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DEFINE(T6, 
DEFINE(T41D, 
DEFINE (T42D, 
DEFINE (BITMAP, 


{2  8  3  7  0}") 

{2  8  3  7  1}") 

{2  8  3  7  2}") 

{2  8  3  7  3}") 


PERM  Content- identifier- logical  (ANY); 

PERM  Content- identifier- layout  {ANY}; 

REQ    Type -of- coding  {$T6   |   $T41D  |   $T42D  | 

$BITMAP) ; 

PERM  Alternative -representation  (ANY) ; 

PERM  Coding-attributes  { 

(        #Compression  (ANY) , 

#Number- of -lines  (ANY), 

#Nuiiiber-of -pels-per- line  (ANY), 

); 

PERM  Content- information  {ANY}; 


16.8.6.3    Geometric  graphics  content  portion 

PERM  Content- identifier- logical  {ANY}; 
PERM  Content- identifier- layout  {ANY}; 
REQ  Alternative-representation  {ANY}; 
PERM  Content- information  {ANY}; 

--  Annex  B.2  contains  a  recommended  functional  subset  of  the  COM 
standard  for  this  DAP  -- 


16.8.7        Additional  usage  constraints 

No  other  usage  constraints  are  currently  defined. 


16.9  INTERCHANGE  FORMAT 

Interchange  format  class  "A"  is  to  be  used  in  this 
application  profile,  as  defined  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules 
for  Abstract  Syntax  Notation  One  (ASN.l),  as  defined  in  ISO 
8825. 


16.9.1        ASN.l  generation  constraints 

There  are  no  additional  constraints,  beyond  ISO  8824 
and  ISO  8825,   imposed  on  the  ASN.l  generation. 
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16.9.2  ASN.l  parsing  constraints 

There  are  no  additional  constraints,  beyond  ISO  8824 
and  ISO  8825,  imposed  on  the  ASN.l  parsing. 

16.9.3  ASN.l  generation  recommendations 

The  focus  of  the  ASN.l  generation  recommendations  is  to 
generate  ASN.l  encodings  that  will  allow  parsing  by  the 
most  rudimentary  of  implementations. 

16.9.3.1    Ordering  of  set  members 

ISO  8824  defines  sets  to  be  unordered  list  of 
values.     It  is  the  generator's  option  to  select  an 
order  for  the  values  of  the  set.     Since  this 
ordering  is  unpredictable  from  one  implementation 
to  the  next,   it  is  recommended  that  generators 
order  the  values  in  a  set  according  to  the  order 
in  which  the  members  appear  in  the  definition  of 
the  set.     The  intent  of  this  recommendation  is  to 
reduce  the  possible  interoperability  problems 
associated  with  the  unpredictable  ordering  of 
members  in  a  set. 


16.9.4        ASN.l  parsing  recommendations 

The  overall  intent  of  these  parsing  recommendations  is 
to  allow  a  high  tolerance  in  the  representation  of  the 
ASN.l  syntax  without  jeoperdizing  the  semantics  of  the 
information  being  conveyed. 

16.9.4.1     Encoding  of  application  comments 

ISO  8613-5  defines  the  encoding  of  the  attribute 
Application  Comments  as  an  octet  string.     This  DAP 
requires  that  the  encoding  within  that  octet 
string  be  in  accordance  with  the  ASN.l  syntax 
specified  in  the  following  module  definition. 

NISTDAPSpecif ication 

DEFINITION  :=  BEGIN 

EXPORTS  Application- Comments -Encoding; 

Application-Comments -Encoding  :=      SEQUENCE  { 

Constraint-name  [0]     IMPLICIT  PrintableString 
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External-data  [1]  EXTERNAL) 


END 
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16. 10  ANNEX  A    IMPLEMENTATION  CONFORMANCE  STATEMENT 

16.10.1      Generator  support  statement  proforma 

The  proforma  for  the  GSS  will  be  provided  in  the  next 
version  of  this  document. 


16.10.2      Receiver  support  statement  proforma 

The  proforma  for  the  RSS  will  be  provided  in  the  next 
version  of  this  document. 


16. 11  ANNEX  B     INFORMATIVE  RECOMMENDATIONS 


16.11.1      Overview  of  technical  specifications 

FrameA  is  a  region  of  the  page  typically  representing  a 
column.     The  direct  subordinates  are  blocks  of  content. 
FrameA  is  at  a  fixed  or  variable  position  within  its 
superior  frame.     The  dimension  orthogonal  to  the  layout 
path  is  fixed  or  variable;   in  the  direction  of  the 
layout  path,   the  dimension  is  the  minimum  size  needed 
to  contain  the  subordinates . 

FrameB  is  a  region  of  the  page,   typically  representing 
a  number  of  columns.     The  direct  subordinates  may  only 
be  frames  of  type  A  or  I .     The  position  is  variable 
(i.e.,  determined  by  a  rule).     The  dimension 
orthogonal  to  the  layout  path  is  maximum  for  the 
position;   in  the  direction  of  the  layout  path,  the 
dimension  is  the  minimum  size  needed  to  contain  the 
subordinates . 

FrameC  is  a  region  of  the  page,   typically  representing 
an  area  of  variable  dimension  within  a  column,   such  as 
is  needed  to  contain  a  paragraph  of  text  or  a  figure. 
This  provides  for  varying  layout  on  pages  (columns  or 
pages)  as  the  document  is  edited.     The  direct 
subordinates  are  blocks  of  content.     The  position  is 
variable  (i.e.,  determined  by  a  rule).     The  dimension 
orthogonal  to  the  layout  path  is  maximum  for  the 
position;  in  the  direction  of  the  layout  path,  the 
dimension  is  the  minimum  size  needed  to  contain  the 
subordinate  block(s) . 
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FrameD  is  a  region  of  the  page,  typically  representing 
an  area  of  variable  dimension  within  a  column, 
containing  a  number  of  items  side  by  side  (e.g.,  text 
flowing  around  a  picture) .     The  direct  subordinates  may 
only  be  frames  of  type  E.     The  position  is  variable 
(i.e.,  determined  by  a  rule).     The  dimension 
orthogonal  to  the  layout  path  is  maximum  for  the 
position;  in  the  direction  of  the  layout  path,  the 
dimension  is  the  minimum  size  needed  to  contain  the 
first  laid  out  subordinate  (e.g.,  the  picture). 

FrameE  is  a  region  of  the  page,  typically  representing 
some  text  or  a  picture,  that  is  side  by  side  with  the 
frames  of  this  type  within  a  superior  frame  of  type  D. 
The  direct  subordinates  are  blocks  of  content.  The 
position  is  variable  (i.e.,  determined  by  a  rule). 
The  dimension  orthogonal  to  the  layout  path  is  the 
minimum  size  needed  to  contain  the  subordinate 
block(s) .     In  the  direction  of  the  layout  path,  the 
dimension  is  either  a  fixed  dimension  or  is  a  computed 
dimension  equal  to  either  the  minimum  size  needed  to 
contain  the  subordinate  block(s)   (e.g.,  picture),  or 
the  maximum  size  for  the  position  (e.g.,  text). 

Frame  F  is  a  region  of  the  page  typically  used  to 
contain  a  footnote.     The  direct  subordinates  are  blocks 
of  content.     The  frame  is  positioned  within  its 
superior  in  reverse  order  at  a  fixed  position  from  its 
superior  in  the  direction  orthogonal  to  the  layout  path 
and  at  a  variable  position  in  the  direction  of  the 
layout  path.  The  dimension  orthogonal  to  the  layout 
path  is  maximum  for  the  position;   in  the  direction  of 
the  layout  path,  the  dimension  is  the  minimum  size 
needed  to  contain  the  subordinate  blocks . 

FrameG  is  a  region  of  the  page,  typically  representing 
a  set  of  pieces  of  content  placed  at  defined  positions. 
This  provides  for  complex,   fixed,   relatively  positioned 
pieces  of  content,   including  overlapping  pieces  of 
content  (e.g.,  overlapping  pictures  or  pictures  and 
text).     The  direct  subordinates  are  blocks  of  content. 
The  position  relative  to  the  superior  is  fixed;  the 
dimensions  are  also  fixed. 

FrameH  is  a  region  of  the  page,  typically  representing 
a  variable  piece  of  logical  information  in  the  header 
or  footer  area  of  a  page  (e.g.,  current  chapter 
number) .     The  direct  subordinates  are  blocks  of 
content.     The  frame,   in  all  cases,   specifies  that  its 
content  is  derived  from  the  use  of  the  attribute 
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"logical  source"  referring  Co  a  logical  object  of 
"header  or  footer  content."     The  position  is  fixed  or 
variable  (i.e.,   determined  by  a  rule.)     The  dimension 
orthogonal  to  the  layout  path  is  maximum  for  the 
position;   in  the  direction  of  the  layout  path,  the 
dimension  is  the  minimum  size  needed  to  contain  the 
subordinate  blocks. 

Frame  I:  A  region  of  the  page  typically  representing  a 
column.     The  frame  may  contain  any  substructure  of 
further  frames  of  any  of  the  types  C,   F,  or  G .  Blocks 
are  not  permitted  directly  subordinate  to  Framel. 
Framel  is  at  a  fixed  or  variable  position  within  its 
superior  frame.     The  dimension  orthogonal  to  the  layout 
path  is  fixed;  in  the  direction  of  the  layout  path,  the 
dimension  is  the  minimum  size  needed  to  contain  the 
subordinates . 

Frame  J  is  a  single  basic  frame  to  contain  header  or 
footer  contents.  This  is  provided  for  compatibility 
with  the  CCITT  Recommendation  T.502. 

Frame  K  is  a  single  basic  frame  to  represent  the  body 
area  of  a  page.  This  is  provided  for  compatibility  with 
the  CCITT  Recommendation  T.502. 


16. 11 .2      ISO  8632  (CGM)  constraints  for  this  DAP 

It  is  recommended  that  geometric  graphics  content 
information  contain  only  those  elements  listed  in  this 
portion  of  the  Annex,   in  addition  to  the  constraints 
imposed  by  ISO  8613-8.     It  is  believed  that  this  subset 
of  the  CGM  is  sufficiently  widely  implemented  to  enable 
interworking  of  geometric  graphics  for  application 
conforming  this  DAP. 

The  content  information  of  a  content  portion 
description  that  conforms  to  this  content  architecture 
is  an  ASN.l  octet  string  representing  a  Computer 
Graphics  Metafile  (CGM)  conforming  to  the  following 
constraints : 

a)  Conform  to  part  1  of  the  ISO  8632  standard; 

b)  Conform  to  the  binary  encoding  defined  in 
part  3  of  the  ISO  8632  standard; 

c)  Consist  of  a  single  picture; 

d)  Conform  to  the  ISO  pdISP  FCG13,  except  as 
noted  with  respect  to  font  and  colour  table 
support; 
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e)  Generalized  Drawing  Primitives  are  ignored; 

f)  ESCAPE  Elements  are  ignored; 

g)  External  Elements  may  be  ignored. 

The  following  list  is  a  description  of  the  constraints 
for  each  of  the  CGM  elements.     Where  an  element  has 
parameters,  recommended  constraints  on  the  values  are 
given.     The  symbol  indicates  that  there  is  no 

recommended  constraint. 

Requirements  in  ISO  8632  and  ISO  8613-8  concerning 
mandatory  elements,  parameters  must  be  fulfilled. 

16.11.2.1  Delimiter  elements 


No-Op 

Begin  Metafile 
End  Metafile 
Begin  Picture 
Begin  Picture  Body 
End  Picture 


See  Note  1 
See  Note  2 


See  Note  2 


16.11.2.2  Metafile  description  elements 


Metafile  Version 
Metafile  Description 
VDC  Type 

Integer  Precision 
Real  Precision 
Index  Precision 
Colour  Precision 
Colour  Index  Precision 
Maximum  Colour  Index 
Colour  Value  Extent 
Metafile  Element  List 
Metafile  Defaults  Replacement 
Font  List 

Character  Set  List 
Character  Coding  Announcer 


See  Note  5 

basic-7-bit,  basic-8-bit 


1 

See  Notes  2,  3 


8,  16 

(0,9.23),  (1,16,16) 
16 


8,  16 
8,  16 


See  Note  4 


16.11.2.3  Picture  descriptor  elements 


Scaling  Mode 

Colour  Selection  Mode 


See  Note  6 


Line  Width  Specification  Mode 
Marker  Size  Specification  Mode 
Edge  Width  Specification  Mode 
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VDC  Extent 
Background  Colour 

16.11.2.4  Control  elements 

VDC  Integer  Precision  16,  32 

VDC  Real  Precision  (0.9,23),  (1,16,16) 

Auxiliary  Colour 

Transparency 

Clip  Rectangle 

Clip  Indicator 


16.11.2.5  Graphical  primitive  elements 

Polyline  See  Note  7 

Disjoint  Polyline  See  Note  7 

Polymarker  See  Note  7 

Text  See  Note  2 

Restricted  Text  See  Notes  2,  8 

Append  Text  See  Notes  2,  8 

Polygon  See  Note  7 

Polygon  Set  See  Note  7 

Cell  Array  See  Note  9 

Rectangle 
Circle 

Circular  Arc  3  Point 
Circular  Arc  3  Point  Close 
Circular  Arc  Centre 
Circular  Arc  Centre  Close 
Ellipse 

Elliptical  Arc 
Elliptical  Arc  Close 


16.11.2.6  Attribute  elements 

Line  Bundle  Index 

Line  Type 

Line  Width 

Line  Colour 

Marker  Bundle  Index 

Marker  Type 

Marker  Size 

Marker  Colour 

Text  Bundle  Index 

Text  Font  Index 

Text  Precision 

Character  Expansion  Factor 

Character  Spacing 

Text  Colour 
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Character  Height 

Character  Orientation 

Text  Path 

Text  Alignment 

Character  Set  Index 

Alternate  Character  Set  Index 

Fill  Bundle  Index 

Interior  Style 

Fill  Colour 

Hatch  Index 

Pattern  Index  1  . .  8 

Edge  Bundle  Index 

Edge  Type 

Edge  Width 

Edge  Colour 

Edge  Visibility 

Fill  Reference  Point 

Pattern  Table  See  Notes  10,  11 

Pattern  Size 

Colour  Table  Specification  See  Notes  12,  13 

Aspect  Source  Flags 


16.11.2.7  External  Elements 


Message 

Application  Data 


No  action 
See  Note  2 


Note  1:      An  arbitrary  sequence  of  n  octets. 
Where  n=0,  1,   ..,  32767.  The 
sequence  of  zero  or  more  octets  is 
for  padding  purposes . 

Note  2:       Support  will  be  provided  for 

strings  with  a  length  up  to  256 
octets,  except  for  data  records 
which  will  support  strings  with  a 
length  up  to  32767  octets. 

Note  3:      The  METAFILE  DESCRIPTION  string 

parameter  will  be  used  to  include 
the  sub- string  "ISO  FCG13"  to  label 
the  content  information  as 
conforming  to  this  agreement.  In 
addition,  generator  of  content  are 
encouraged  to  append  a  sub -string 
that  identifies  the  company  and 
product  that  produced  the  CGM. 
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Note  4:       The  METAFILE  DEFAULTS  REPLACEMENT 
element  shall  not  be  partitioned. 
No  part  of  the  element  will  be 
partitioned.     Multiple  occurances 
of  the  MDR  element  may  be  used  to 
avoid  the  need  for  partitioning. 
The  MDR  element  must  appear  in  the 
CGM  to  establish  the  defaults  for 
TEXT  PRECISION  and  any  other 
elements  whose  defaults  are 
different  than  those  specified  in 
ISO  8632-1  and  -3. 

Note  5:       Only  those  character  set  that  are 
permitted  in  character  content  can 
be  specified  in  geometric  graphics 
content.     Refer  to  7.1,  Document 
profile,   for  constraints  on 
character  sets  in  character 
content . 

Note  6:      The  Scale  Factor  parameter  of 

SCALING  MODE  element  is  always  a 
32-bit  floating  point  value,  even 
when  the  REAL  PRECISION  has 
selected  fixed  point  for  other  real 
numbers.     It  is  not  apparent  in  ISO 
8632  what  the  precision  of  this 
floating  point  value  is  when  fixed 
point  has  been  selected.  Its 
precision  shall  be  (0,9,23). 

Note  7:       The  minimum  support  for  the  length 
of  point  lists  is  1024  elements. 

Note  8:       The  complete  restricted  text 

string,   including  appended  text, 
shall  be  included  in  a  metafile 
conforming  to  this  agreement.  The 
complete  restricted  text  string 
shall  be  scaled  isotropically  such 
that  the  specified  aspect  ratio  for 
the  text  is  not  distorted  and  the 
string  fits  into  the  text  extent 
parallelogram . 

Note  9:       The  minimum  support  for  the  length 
of  colour  lists  parameter  for  the 
CELL  ARRAY  element  is  1,048,576. 
This  supports  a  1024x1024  image. 
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Note  10:     The  PATTERN  TABLE  element  has  an 

unspecified  effect  when  it  appears 
in  a  picture  subsequent  to  any 
graphical  primitives.     The  PATTERN 
TABLE  element  shall  appear  prior  to 
any  graphical  primitive  element  to 
assure  that  interpreting  systems 
without  dynamic  pattern  update  can 
render  the  intended  effect. 


Note  11:     The  minimum  support  for  the  length 
of  the  Colour  Array  parameter  for 
the  PATTERN  TABLE  element  is  2048. 
This  will  support  8  patterns  of 
16x16. 


Note  12:     The  COLOUR  TABLE  element  has  an 

unspecified  effect  when  it  appears 
in  a  picture  subsequent  to  any 
graphical  primitives .     The  COLOUR 
TABLE  element  shall  appear  prior  to 
any  graphical  primitive  elements  to 
assure  that  interpreting  systems 
without  dynamic  colour  update  can 
render  the  intended  effect. 

Note  13:     The  minimum  support  for  the  length 
of  the  Colour  List  parameter  in  the 
COLOUR  TABLE  element  is  61.  This 
will  support  a  63  entry  colour 
table . 


16.11.3       Interoperability  with  SGML  Applications 

The  recommended  method  for  the  exchange  of  documents 
between  Standard  Generalized  Markup  Language  (ISO  8879, 
SGML)  based  systems  and  systems  based  on  this  ODA 
document  application  profile  is  by  means  of  exchanging 
a  document  representation  conforming  to  these 
agreements  in  an  encoded  form  of  the  SGML  language 
known  as  the  Office  Document  Language  (ODL) .     ODL  is  a 
standardized  SGML  application  for  representing 
documents  conforming  to  the  ODA  base  standard.     Such  a 
representation  can  be  converted  into  the  Office 
Document  Interchange  Format  (ODIF)  supported  by  these 
agreements . 
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17.     FUTURE  OFFICE  DOCUMENT  ARCHITECTURE  (PDA) 

Editor's  Note:  This  section  will  contain  the  new 
text  relating  to  Office  Document 
Architecture  (ODA)  Agreements. 
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1 8    NETWORK  MANAGEMENT 


18.1  INTRODUCTION 

Within  the  community  of  OSI  researchers,  users,  and  vendors,  there  is  a  recognized  need  to  address  the 
problems  of  initiating,  terminating,  monitoring,  and  controlling  communication  activities  and  assisting  in  their 
harmonious  operation,  as  v^^ell  as  handling  abnormal  conditions.  The  activities  that  address  these  problems 
are  collectively  called  network  management. 

Network  management  can  be  viewed  as  the  set  of  operational  and  administrative  mechanisms  necessary 
to: 

a.  bring  up,  enroll,  and/or  alter  network  resources, 

b.  keep  network  resources  operational, 

0.        fine  tune  these  resources  and/or  plan  for  their  expansion, 

d.  manage  the  accounting  of  their  usage,  and 

e.  manage  their  protection  from  unauthorized  use/tampering. 

As  such,  network  management  is  typically  concerned  with  management  activities  in  at  least  the  following 
five  functional  areas:  configuration  management,  fault  management,  performance  management,  accounting 
management,  and  security  management.  In  order  to  accomplish  these  management  activities,  information 
must  be  exchanged  among  open  systems. 

In  Part  18,  there  are  Implementation  Agreements  (lA's)  for  providing  interoperable  OSI  management 
information  communication  services  among  OSI  systems.  Also  contained  here  are  agreements  on 
management  information.  These  agreements  pertain  to  the  exchange  of  management  information  and 
management  commands  between  open  systems  operating  in  a  multivendor  environment.  For  example,  one 
goal  is  to  ensure  that  a  management  system  built  by  one  vendor  can  manage  objects  built  by  another 
vendor. 


18.1.1  References 

The  following  documents  are  referenced  in  the  statements  of  the  agreements  relating  to  OIW  OSI  network 
management. 

OSI  Systems  Management  References: 

[ADDRMVP]     ISO/IEC  9596/DAD  2,  Common  Management  Information  Protocol  Specification: 
Addendum  2  (Add/Remove  Protocol),  ISO/IEC  JTC1/SC21,  1  February  1990. 
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[ADDRMVS]     ISO/IEC  9595/DAD  2,  Common  Management  Information  Service  Definition: 
Addendum  2  (Add/Remove  Service),  ISO/IEC  JTC1/SC21,  1  February  1990. 


[CANGETP]     ISO/IEC  9596/DAD  1 ,  Common  Management  Information  Protocol  Specification: 
Addendum  1  (CancelGet  Protocol),  ISO/IEC  JTC1/SC21,  1  February  1990. 

[CANGETS]     ISO/IEC  9595/DAD  1,  Common  Management  Information  Service  Definition: 
Addendum  1  (CancelGet  Service),  ISO/IEC  JTC1/SC21,  1  February  1990. 

[CMIP]  ISO/IEC  9596-2,  Information  Processing  Systems  -  Open  Systems  Interconnection 

-  Management  Information  Protocol  Specification  -  Part  2:  Common  Management 
Information  Protocol,  6  December  1989. 

[CMIS]  ISO/IEC   9595-2,    Information    Processing   Systems   -      Open  Systems 

Interconnection  -  Management  Information  Service  Definition  -  Part  2:  Common 
Management  Information  Service,  6  December  1 989. 

[MIM]  ISO/IEC  DIS  10165-1,  Information  Processing  Systems  -  Open  Systems 

Interconnection  -  Management  Information  Services  -  Structure  of  Management 
Information  -  Part  1 :  Management  Information  Model,  ISO/IEC  JTC1/SC21  N5252, 
June  1990. 


Other  OSI  References: 


[ASN1]  ISO  8824,  Information  Processing  Systems  -  Open  System  Interconnection 

Specification  of  Abstract  Syntax  Notation  One  (ASN.1),  19  May  1987. 


18.2  SCOPE  AND  FIELD  OF  APPLICATION 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

18.3  STATUS 

(Refer  to  the  Working  Implementation  Agreements  Document.) 


18.4  ERRATA 

Editor's  Note:    "Defect  Report*  material  (including  applicability)  may  be  included  here. 

(Refer  to  the  Working  Implementation  Agreements  Document.) 


18-2 


18.5  MANAGEMENT  FUNCTIONS  AND  SERVICES 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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18.6  MANAGEMENT  COMMUNICATIONS 


18.6.1    Association  Policies 

(Refer  to  the  Working  Implementation  Agreemerrts  Document.) 


18.6.2   General  Agreements  on  Users  of  CMIS 

The  following  agreements  pertain  to  the  first  phase  of  network  management  implementors  agreements  (I As) . 
These  agreements  are  based  on  the  standard  defined  in  [CMIS],  [CMIP],  [ADDRMVP]  and  [ADDRMVS] 
constrain  the  users  of  CMIS  services  and  not  the  implementation  of  CMIP  itself. 


18.6.2.1      Object  Naming 

Object  Naming  will  be  accomplished  using  Distinguished  Name  or  Local  Distinguished  Name.  Use  of 
nonspecific  form  is  outside  the  scope  of  these  agreements. 


18.6.2.2      Multiple  Object  Selection 

Multiple  Object  Selection  applies  to  all  management  operations  except  M-EVENT-REPORT,  M-CREATE  and 
M-CANCEL-GET. 


18.6.2.2.1  Scoping 

These  network  management  lAs  specify  that  scoping  will  be  used  as  specified  in  [CMIS]  6.5.1,  8.3.1.1.5, 
8.3.2.1.6,  8.3.3.1.6,  8.3.5.1.5. 


18.6.2.2.2  Filtering 

These  network  management  lAs  specify  that  filtering  will  be  used  as  specified  in  [CMIS]  6.5.2,  8.3.1.1.6, 
8.3.2.1.7,  8.3.3.1.7,  8.3.5.1.6. 

If  a  system  receives  a  filter  parameter  that  it  is  unable  to  process,  it  must  return  the  error  "complexity 
limitation",  including  the  CMISFilter  requested. 

If,  in  the  process  of  filtering  from  a  set  of  selected  entities,  there  are  no  managed  objects  selected,  the 
system  must  return  an  empty  response  consisting  of  an  Invoke  ID  and  no  response  argument. 
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18.6.2.2.3  Synchronization 

In  order  to  support  interoperability  between  managing  systems  and  managed  systems,  these  network 
management  lAs  define  that  the  default  synchronization  (i.e.,  BestEffort)  must  be  supported  by  all 
conforming  systems.  Atomic  synchronization  may  also  be  supported  as  an  option. 

If  a  performer  is  unable  to  comply  with  a  synchronization  request  specified  by  an  invoker,  the  performer  must 
return  the  error  "synchronization  not  supported"  with  the  parameter  indicating  the  synchronization  not 
supported. 


18.6.2.2.4       Muitipie  Replies 

These  network  management  lAs  specify  the  use  of  multiple  replies  as  specified  in  [CMIS]  7.1,  7.2.3. 


18.6.2.3      Current/Event  Time 

The  time  value  that  is  reported  to  CMIS,  if  provided,  should  be  as  close  as  possible  to,  but  not  before,  the 
actual  time  that  the  operation  to  which  the  reported  time  value  applies  occurred.  This  constraint  is  stipulated 
to  provide  the  most  accurate  timestamp  for  temporal  ordering  of  operations  and  events  on  a  single  open 
system. 

For  these  network  management  I  As,  the  encoding  of  the  Current  Time  parameters  is  ASN.1  Generalised 
Time,  UTC  Type,  as  specified  in  [ASN1  ]  clause  32.3,  b)  and  c),  with  the  precision  of  the  time  representation 
indicating  the  granularity  of  the  time  measurement.  For  example,  the  string  19890613123012.333-0500 
represents  a  local  time  of  12:30:12  (and  333  msecs)  on  13th  June  1989,  in  a  time  zone  which  is  5  hours 
behind  GMT. 


1 8.6.2.4      Access  Control 

Conformant  implementations  are  not  required  to  use  this  field.  The  Access  Control  field,  if  provided  by  the 
invoker  in  CMIS  request  indicators,  may  be  ignored  by  responding  systems  which  do  not  support  access 
control.  These  systems  must  not  reject  a  request  on  the  basis  of  the  presence  of  access  information.  The 
invoker  may  interpret  this  as  acceptance  of  the  access  control  parameter. 


18.6.2.5  CI\/!iS  Functional  Units 

Only  the  Kernel  Functional  Unit  must  be  supported.  Other  functional  units  except  Extended  Service  are 
optional  and  their  use  must  be  negotiated  as  specified  in  [CMIS].  Extended  Service  is  not  within  the  scope 
of  these  agreements.  Negotiation  for  its  "non  use"  must  be  supported. 

18.6.2.6  CI\/IIS  Parameters 


The  CMIS  globalForm  must  be  used  for  the  following  parameters: 
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action  type  id 
attribute  id 
event  type  id 
object  class 

Use  of  localForm  is  outside  the  scope  of  tfiese  agreements. 
18.6.3   Specific  Agreements  on  Users  of  CMIS 

These  agreements  pertain  to  the  first  phase  of  network  management  implementors  agreements  (I  As).  These 
agreements  are  based  on  the  standard  defined  in  [CMIS]  and  [ADDRMVS].  The  agreements  in  this  clause 
have  been  defined  in  terms  of  those  capabilities  necessary  to  support  the  functions  and  services  defined 
in  clause  18.5  (Management  Functions  and  Services)  of  these  agreements.  These  agreements  constrain 
the  users  of  CMIS  services  and  not  the  implementation  of  CMIP  itself. 

The  parameter  presence  information  in  the  tables  in  this  clause  are  repeated  from  [CMIS]  and  have  the  same 
meaning  as  in  the  standard.  They  are  repeated  for  reader  convenience.  In  addition,  these  tables  provide 
references  to  text  clauses  where  agreements  are  stated  relative  to  parameters  in  each  table.  The  lack  of  a 
reference  signifies  no  agreement  beyond  the  base  standard. 


18.6.3.1  M-Event-Report 

The  following  agreements  and  clarifications,  pertinenttosection8.2ofthe  base  standard  [CMIS]  and  section 
6.3  of  the  base  standard  [CMIP]  and  regarding  the  M-EVENT-REPORT  service,  are  included  within  these 
network  management  lAs. 

Clause  1 8.5  (Management  Functions  and  Services)  of  these  agreements  defines  some  of  the  types  of  Event 
Reports  that  may  be  sent. 


18.6.3.1.1       Event  Argument 

All  arguments  defined  for  the  particular  event  type  of  the  managed  object  class  (see  sec.  18.7,  Management 
Information  Agreements)  for  the  M-EVENT-REPORT  must  be  supplied  in  the  Event  Argument  parameter. 
The  Event  Information  and  Event  Reply  parameters  shall  be  supplied  as  specified  for  the  event  type. 


18.6.3.1.2      Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  refined  by  the  referenced  agreement. 
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Table  1 :      M-EVENT  REPORT  Parameters 


Item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

18.6.4 

2 

Mode 

M 

_ 

3 

Managed  Object  Class 

M 

U 

18.6.2.6 

4 

Managed  Object  Instance 

M 

U 

18.6.2.1 

5 

Event  Type 

M 

c= 

18.6.2.6 

6 

Event  Time 

U 

18.6.2.3 

7 

Event  Information 

U 

18.6.3.1.1 

8 

Current  Time 

u 

18.6.2.3 

9 

Event  Reply 

c 

10 

Errors 

c 

18.6.4.4 

18.6.3.2  M-Get 

The  following  agreements  and  clarifications,  pertinent  to  section  8.3.1  of  the  base  standard  [CMIS]  and 
section  6.4  of  the  base  standard  [CMIP]  and  regarding  the  M-GET  service,  are  included  within  these  network 
management  lAs. 


18.6.3.2.1       Successful  Response 

For  a  successful  M-GET  operation,  the  performer  shall  return  (in  the  Attribute  List  parameter)  either  the 
attribute  values  for  all  attributes  explicitly  requested  (in  the  Attribute  Identifier  List  parameter),  or  the  attribute 
values  for  all  attributes  defined  for  the  managed  object(s)  selected  (if  the  Attribute  Identifier  List  is  omitted). 


18.6.3.2.2      Partially  Successful  or  Unsuccessful  Response 

For  a  partially  successful  M-GET  operation,  where  only  some  attribute  values  were  retrieved,  the  performer 
shall  return  (in  the  Errors  parameter,  specifically  encoded  as  GetListError)  all  attribute  ids  and  their 
corresponding  values  that  were  successfully  retrieved  from  the  set  of  attributes  selected  as  described  above, 
together  with  all  attribute  ids,  and  the  corresponding  error  codes,  for  each  of  the  attributes  for  which  errors 
were  detected.  All  attributes  requested  by  the  invoker  must  be  processed,  with  either  a  value  or  an  error 
code  returned  for  each. 


18-6 


June  1990  (Stable)) 

18.6.3.2.3  Multiple  Replies 

For  the  final  reply  of  a  series  of  multiple  relies  or  the  single  reply  where  no  objects  were  selected  when 
filtering  has  been  specified,  the  GetResult  is  omitted.  Hence  Managed  Object  Class,  Managed  Object 
Instance,  Current  Time  and  Attribute  List  are  all  omitted  in  these  cases. 

18.6.3.2.4  Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  refined  by  the  referenced  agreement. 

Table  2:       M-GET  Parameters 


Item 

Parameter  Name 

Req/ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

18.6.4 

o 

LinKeu  loeniiTier 

C 

18.6.4 

3 

Base  Object  Class 

M 

18.6.2.6 

4 

Base  Object  Instance 

M 

18.6.2.1 

5 

Scope 

U 

18.6.2.2.1 

6 

Filter 

U 

18.6.2.2.2 

7 

Access  control 

U 

18.6.2.4 

8 

Synchronization 

U 

18.6.2.2.3 

9 

Attribute  Identifier  List 

U 

18.6.2.6 

10 

Managed  Object  Class 

C 

18.6.2.6 

11 

Managed  Object  Instance 

c 

18.6.2.1 

12 

Current  Time 

u 

18.6.2.3 

13 

Attribute  list 

c 

18.6.2.6,  18.6.3.2.1, 
18.6.3.2.3 

14 

Errors 

c 

18.6.3.2.2,  18.6.4.4 

18.6.3.3  M-Set 

The  following  agreements  and  clarifications,  pertinent  to  section  8.3.2  of  the  base  standard  [CMIS]  and 
section  6.5  of  the  base  standard  [CMIP]  and  regarding  the  M-SET  service,  are  included  within  these  network 
management  lAs. 
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18.6.3.3.1  Successful  Response 

For  a  successful  M-SET  confirmed  operation,  the  performer  shall  return  (in  the  Attribute  List  parameter)  the 
attribute  values  for  all  attributes  explicitly  specified  (in  the  Attribute  List  parameter)  indicating  their  new 
values. 

18.6.3.3.2  Partially  Successful  or  Unsuccessful  Response 

For  a  partially  successful  M-SET  operation,  where  only  some  attribute  values  were  modified,  the  performer 
shall  return  (in  the  Errors  parameter,  specifically  encoded  as  SetListError)  all  attribute  ids  and  their 
corresponding  values  that  were  successfully  modified  from  the  set  of  attributes  ids  and  values  supplied,  and 
all  attribute  ids  and  the  corresponding  error  codes  for  each  of  the  attributes  for  which  errors  were  detected. 
All  attributes  requested  by  the  invoker  must  be  processed,  with  either  a  value  or  an  error  code  returned  for 
each. 


18.6.3.3.3       Multiple  Replies 

For  the  final  reply  of  a  series  of  multiple  relies  or  the  single  reply  where  no  objects  were  selected  when 
filtering  has  been  specified,  the  SetResult  is  omitted.  Hence  Managed  Object  Class,  Managed  Object 
Instance,  Current  Time  and  Attribute  List  are  all  omitted  in  these  cases. 


1 8.6.3.3.4      Add/Remove  Response 

Where  multi-valued  attributes  are  involved  in  an  M-SET  operation  [ADDRMVS] ,  the  values  returned  after  any 
modification  operation  must  be  the  full  set  of  values  of  that  attribute  and  not  just  the  values  that  were 
modified  (e.g.,  added  or  removed). 


1 8.6.3.3.5      Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  specified  in  [CMIS]  unless  those 
conditions  are  modified  by  the  referenced  agreements. 
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item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

11  IVUKc;  lUUllUllol 

M 

KAf—\ 
M(-) 

■in  R  A 
1  o.o.»t 

o 

LiiiKec]  iu6niiii6r 

1  O.D.»* 

o 
o 

IVIOU6 

M 

A 
H 

M 

c 

M 
M 



1  ft  R  O  1 

R 

KJ 

U 

1  Q  C  O  O  1 

7 

Filter 

u 

- 

18.6.2.2.2 

8 

Access  control 

u 

- 

18.6.2.4 

9 

Synchronization 

u 

18.6.2.2.3 

10 

Managed  Object  Class 

C 

18.6.2.6 

11 

Managed  Object  Instance 

- 

c 

18.6.2.1 

12 

Modification  List 

M 

18.6.2.6,  18.6.3.3.1, 
18.6.3.3.3,  18.6.3.3.4 

13 

Attribute  List 

u 

18.6.2.6,  18.6.3.3.1, 
18.6.3.3.3 

14 

Current  Time 

u 

18.6.2.3 

15 

Errors 

c 

18.6.3.3.2,  18.6.4.4 

18.6.3.4  M-Action 

The  following  agreements  and  clarifications,  pertinent  to  section  8.3.3  of  the  base  standard  [CMIS]  and 
section  6.6  of  the  base  standard  [CMIP]  and  regarding  the  M-ACTION  service,  are  included  within  these 
network  management  lAs. 

18.6.3.4.1       Multiple  Objects 

When  multiple  objects  are  selected  for  an  M-ACTION  operation,  there  is  no  ordering  implied  between 
selected  objects.  If  the  ordering  is  important,  the  requesting  system  may  use  separate  operations,  for 
individual  object  instances,  in  the  desired  order. 
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18.6.3.4.2      Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  modified  by  the  referenced  agreements. 

Table  4:      M-ACTION  Parameters 


Item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

18.6.4 

2 

Linked  Identifier 

C 

18.6.4 

3 

Mode 

M 

4 

Base  Object  Class 

M 

18.6.2.6 

5 

Base  Object  Instance 

M 

18.6.2.1 

6 

Scope 

u 

18.6.2.2.1 

7 

Filter 

u 

18.6.2.2.2 

8 

Managed  Object  Class 

C 

18.6.2.6 

9 

Managed  Object  Instance 

c 

18.6.2.1 

10 

Access  control 

U 

18.6.2.4 

11 

Synchronization 

U 

18.6.2.2.3 

12 

Action  Type 

M 

C(=) 

18.6.2.6 

13 

Action  Information 

U 

14 

Current  Time 

u 

18.6.2.3 

15 

Action  Reply 

c 

16 

Errors 

c 

18.6.4.4 

18.6.3.5  M-Create 

The  following  agreements  and  clarifications,  pertinent  to  section  8.3.4  of  the  base  standard  [CMIS]  and 
section  6.7  of  the  base  standard  [CMIP]  and  regarding  the  M-CREATE  service,  are  included  within  these 
network  management  lAs, 

18.6.3.5.1       Managed  Object  Instance 

The  Managed  Object  Instance  request  parameter  may  be  present  or  absent  depending  on  whether  the 
invoker  supplies  the  instance  name  orthe  performer  assigns  the  instance  name  automatically.  The  definition 
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of  each  Managed  Object  Class  shall  define  whether  the  Instance  name  may  be  supplied  by  the  invoker,  or 
must  be  assigned  by  the  performer.  This  definition  shall  apply  to  every  management-initiated  creation  of 
instances  of  that  managed  object  class. 


18.6.3.5.2  Attribute  Values 

The  values  of  each  of  the  attributes  of  the  newly  created  object  are  derived  as  defined  in  [MIM]  5.2.2.1 .  If 
none  of  these  methods  provides  a  value  for  any  one  attribute,  then  the  operation  shall  be  considered  to  have 
failed,  i.e.,  no  new  instance  is  created,  and  the  error  code  'Missing  Attribute  Value'  shall  be  returned. 

18.6.3.5.3  Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  modified  by  the  referenced  agreement. 

Table  5:      M-CREATE  Parameters 


Item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

18.6.4 

2 

Managed  Object  Class 

M 

C 

18.6.2.6 

3 

Managed  Object 
Instance 

U 

c 

18.6.2.1,  18.6.3.5.1 

4 

Superior  Object  Instance 

U 

18.6.2.1 

5 

Access  Control 

U 

18.6.2.4 

6 

Reference  Object 
Instance 

U 

18.6.2.1 

7 

Attribute  List 

U 

c 

18.6.2.6,  18.6.3.5.2 

8 

Current  Time 

u 

18.6.2.3 

9 

Errors 

c 

18.6.3.5.2.  18.6.4.4 

18.6.3.6  M-Delete 

The  following  agreements  and  clarifications,  pertinent  to  section  8.3.5  of  the  base  standard  [CMIS]  and 
section  6.8  of  the  base  standard  [CMIP]  and  regarding  the  M-DELETE  service,  are  included  within  these 
Phase  1  network  management  lAs. 
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18.6.3.6.1  Deletion  of  Objects  Containing  Objects 

The  error  'Processing  Failure'  must  be  returned  if  a  managed  object  has  existing  contained  objects  and  the 
behavior  defined  for  that  object  prohibits  its  deletion  unless  all  contained  objects  have  been  deleted. 

18.6.3.6.2  Parameter  Agreements 

Conditional  parameters  (C)  shall  be  included  according  to  the  conditions  defined  in  [CMIS]  unless  those 
conditions  are  modified  by  the  referenced  agreements. 

Table  6:       M-DELETE  Parameters 


Item 

Parameter  Name 

Req/Ind 

Rsp/Conf 

Text  Reference 

1 

Invoke  Identifier 

M 

M(=) 

18.6.4 

2 

Linked  Identifier 

C 

18.6.4 

3 

Base  Object  Class 

M 

18.6.2.6 

4 

Base  Object  Instance 

M 

18.6.2.1 

5 

Scope 

U 

18.6.2.2.1 

6 

Filter 

U 

18.6.2.2.2 

7 

Access  control 

U 

18.6.2.4 

8 

Synchronization 

U 

18.6.2.2.3 

9 

Managed  Object  Class 

C 

18.6.2.6 

10 

Managed  Object  Instance 

c 

18.6.2.1 

11 

Current  Time 

u 

18.6.2.3 

12 

Errors 

c 

18.6.3.6.1,  18.6.4.4 

18.6.4   Specific  Agreements  on  CMIP 

These  agreements  pertain  to  the  first  phase  of  network  management  implementors  agreements  (lAs).  These 
agreements  are  based  on  the  standard  defined  in  [CMIP]  and  [ADDRMVP].  The  agreements  in  this  clause 
have  been  defined  in  terms  of  those  capabilities  necessary  to  support  the  functions  and  services  defined 
in  clause  18.5  (Management  Functions  and  Services)  of  these  agreements. 

These  netv\/ork  management  lAs  make  no  agreements  beyond  the  specifications  in  [CMIP]  and  [ADDRMVP], 
except  the  following: 
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18.6.4.1  Invoke/Linked  Identifier  Size 

Invoke  Identifiers  and  Linked  Identifiers  must  be  encoded  in  an  integer  of  four  (4)  octets  maximum  length. 

18.6.4.2  Version 

Protocol  Version  2  (only)  is  supported. 

1 8.6.4.3  Linked  Reply  Values 

Responders  must  send  a  linked  reply  value  that  corresponds  to  the  original  invoke  operation  value. 

1 8.6.4.4  Error  Codes 

Responders  must  send  error  types  that  correspond  to  the  operation  definition  for  the  original  invoke. 

18.6.5   Services  Required  by  CiVIIP 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

18.7  MANAGEMENT  INFORMATION 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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19.     REMOTE  DATABASE  ACCESS  (RDA) 

Editor's  Note:  This  section  serves  as  a  placeholder 
for  text  provided  by  the  newly- formed 
Remote  Database  Access  (RDA)  Special 
Interest  Group, 
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Manufacturing  Message  Specification  (MMS) 

1  Introduction 

(Refer  to  Working  Agreements,  Dated  September,  1990.) 

2  Scope  and  Field  of  Application 
(Refer  to  Working  Agreements,  Dated  September,  1990.) 

3  References 

(Refer  to  Working  Agreements,  Dated  September,  1990.) 

4  Definitions 

(Refer  to  Working  Agreements,  Dated  September,  1990.) 

5  Errata 

(Refer  to  Working  Agreements,  Dated  September,  1 990.) 

6  Status 

(Refer  to  Working  Agreements,  Dated  September,  1990.) 

7  General  Agreements 

(Refer  to  Working  Agreements,  Dated  September,  1 990.) 

8  Service-Specific  Agreements 

(Refer  to  Working  Agreements.  Dated  Septemt)er.  1990.) 
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(Refer  to  Working  Agreements,  Dated  September,  1990.) 
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B      DIS  9506  Modifications  Required  For  Backwards  Compatibility 
B.1  Introduction 

This  annex  is  an  integral  part  of  this  part  It  documents  the  modifications  to  DIS  9506  required  to  describe 
implementations  for  which  the  agreements  of  this  part  provide  backwards  compatibility.  This  annex  as 
applied  to  DIS  9506  is  referred  to  as  Version  0. 

B2.  References 

[1]  MMS/1  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Sen/ice  Definition,  December  1987 
[2]  MMS/2  Manufacturing  Message  Specification  -ISO  DIS  9506  -  Protocol  Specification,  December  1 987 
[3]  NBS  OSI  Implementors  Workshop  Agreements  -  December  1987 

B.3  General 

B.3.1  Imptementatkxi  Base 

Version  0  is  based  upon  Reference  [3]  in  8.2  as  it  applies  to  MMS. 
B.3.2  Rules  of  Extensibifity 

The  following  sentence  is  appended  to  the  last  paragraph  in  section  8.2.1 .1 .5.2  Proposed  Parameter  CBB 
and  the  last  paragraph  in  section  8.2.1.2.5.2  Negotiated  Parameter  CBB  of  DIS  9506-1. 

•Any  additional  bits  shall  be  ignored." 
B.4       Modifications  to  the  Protocol  definitions 


B.4.1  Page  39.  Section  7.5.2  of  DIS  9506-2 

CHANGE 
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reportEventEnrollmentStatus   {60]  IMPUCn"  ReporlEventEnrollmentStatus-Request. 

TO 

reportEventEnrollmentStatus   [60]  ReportEventEnrolimentStatus-Request. 
Page  49,  Section  7.&4,  DIS  9506-2 

CHANGE 

ApplicationReference  ::=  SEQUENCE  { 
ap-tltle  ISO-8650-ACSE-1.AP-title  OPTIONAL, 

ap-invocation-id       ISO-86  SO-ACSE-LAP-invocation-id  OPTIONAL, 
ae-qualifier  ISO-8650-ACSE-1  .AE-quaiifier  OPTIONAL, 

ae-invocatlon-id        ISO-8650-ACSE-1.AE-invocatlon-id  OPTIONAL 
} 


TO 


ApplicationReference  ::=  SEQUENCE  { 
ap-title  [0]  OBJECT  IDENTIFIER  OPTIONAL, 

ap-invocation-id  [1]  INTEGER  OPTIONAL, 
ae-qualifier  [2]  INTEGER  OPTIONAL, 

ae-invocation-id        [3]  IfTTEGER  OPTIONAL 
} 


B.4.3  Page  95.  Section  1ZZ1  of  DIS  9506-2 

CHANGE 

structure   [2]  IMPUCIT  SEQUENCE  OF  SEQUENCE  { 

TO 

stmcture   [2]  IMPUCIT  SEQUENCE  { 

B.4.4         Page  96,  Section  12.3.1  of  DIS  9506-2 
CHANGE 

named    [4]  IMPUCIT  SEQUENCE  { 

TO 

named    [5]  IMPUCIT  SEQUENCE  { 
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B.4.5  Page  98.  Section  12.42.  of  DIS  9506-2 

CHANGE 

generalized-time  (10]  IMPLICIT  GeneralizeiJTime, 

TO 

generalized-time   [11]  IMPLICIT  GeneralizecTTime, 

6.4.6         Page  138.  Section  15.14  Of  DIS  9506-2 
CHANGE 

additionalDetail       [9]  IMPUCIT  EE-Additional-Detail  OPTIONAL 

TO 

additionalDetail       [9]  EE-Additional-Detail  OPTIONAL 

B.4.7  Page  166,  Section  17.10  of  DIS  9506-2 

CHANGE  the  transfer  syntax  object  identifier  value  from 
{  iso  asnl(1)  basic-encodingO)  } 

TO 

{  joint-iso-ccitt  asn1(1)  basic-encoding (1 )  } 
B.5       Behavioral  Requirements 
B.5.1  Filenames 

File  Names  are  specified  in  accordance  with  the  NBS  Implementors'agreements  for  FTAM  Reference  [3]  in 
B.2. 

B.5.2         lden%  Service 

In  the  Identify  service,  the  vendor,  model  and  revision  fields  may  be  of  any  length,  but  only  the  first  64, 1 6, 
and  1 6  octets  respectively  are  treated  as  significant. 
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B.5.3         initiate  Service 
An  MMS  Client  will: 

1.  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Sen/  Outstanding  Called  parameter 
in  the  Initiate  service  when  initiating  the  application  association  (calling). 

2.  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Sen/  Outstanding  Calling  parameter  in  ■ 
the  Initiate  service  when  receiving  the  application  association  initiation  (called). 

An  MMS  Server  will: 

1.  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling  parameter 
in  the  Initiate  service  when  initiating  the  application  association  (calling). 

2.  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Called  parameter  in 
the  Initiate  service  when  receiving  the  application  association  initiation  (called). 


B.5.3.1  Minimum  Segment  Size 

MMS  implementations  are  able  to  parse  and  process  512  octets  of  MMSpdu  as  they  are  encoded  in  ASN.1 
basic  encoding  mles. 


B.5.3.2  Maximum  Segment  Size 

The  Max  Segment  Size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
negotiated  transfer  syntax.  This  size  will  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
PDU,  initiate-Response  PDU,  and  the  initiate-Error  PDU.  The  max  segment  size  will  be  negotiated  during 
connection  initiation  using  the  Proposed  Max  Segment  Size  and  Negotiated  Max  Segment  Size  parameters 
of  the  MMS  initiate  sen/ice. 

The  Max  Segment  Size  will  be  applied  as  follows: 

Any  received  MMSpdu  which  is  less  than  or  equal  to  the  Max  Segment  Size  will  be  property 
parsed  and  processed. 

An  MMS  implementation  will  not  send  an  MMSpdu  whose  size  exceeds  the  Max  Segment  Size. 


B.5.4         Abstract  Syntax  Name 

The  ASN.  1  object  identifier  value  for  the  abstract  syntax  name  will  t>€  the  same  as  specified  on  page  1 66, 
section  17.10  of  DIS  9506-2. 
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B.5.5         Application  Context  Name 

The  ASN.  1  object  identifler  value  for  the  application  context  name  wilt  be  the  same  as  specified  on  page  1 66, 
section  17.1 1  of  DIS  9506-2. 

An  MMS  implementation  ignores  the  Application  Context  Name  in  the  A-Assodate  indication  and  the  A- 
Associate  confirm. 


B.5.6  Minor  Version  Numtser 
The  Minor  Version  Numfc>er  is  zero. 


B.6       Parameter  CBB  Subset 

The  following  subset  of  MMS  Parameter  CBBs  were  considered  during  preparation  of  this  appendix. 

STRl, 
NEST, 
VADR, 
VNAM 


B.7       Service  Subset 

The  following  subset  of  MMS  services  were  considered  during  preparation  of  this  appendix. 
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Initiate 

Conclude 

Cancel 

Status 

GetNameList 

Identify 

Unsol icitedS tatus 

GetCapabilityList 

InitiateDownloadSequence 

DownloadSegment 

TerminateDovmloadSequence 

InitiateUploadSequence 

Up 1 oadS  egment 

TerminateUploadSequence 

RequestDomainDownload 

RequestDomainUpload 

LoadDoma  inContent 

StoreDomainContent 

DeleteDomain 

GetDoma  inAttr ibutes 

Read 

Write 

InfonnationReport 

GetVariableAccessAttributes 

Input 

Table  MMS  Service  Subset 


Output 

TakeControl 

RelinquishControl 

ReportSemaphoreStatus 

ReportPoolSemaphoreStatus 

ReportSemaphoreEntryS tatus 

CreateProgramlnvocation 

DeleteProgramlnvocation 

Start 

Stop 

Resume 

Reset 

Kill 

GetProgramlnvocationAttr ibutes 
ObtainFile 

GetEventConditionAttr ibutes 

ReportEventConditionStatus 

GetAlannSummary 

ReadJournal 

WriteJournal 

Initial izeJournal 

CreateJournal 

DeleteJournal 

ReportJournalS tatus 
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ISO  10021-6  Information  Processing  Systems  -  Text  Communication  - 
MOTIS  -  Protocol  Specifications. 

ISO  10021-7  Information  Processing  Systems  -  Text  Communication  - 
MOTIS  -  Interpersonal  Messaging  System. 
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Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  I:     General  Introduction,  ISO 
8571-1:  1988(E). 

Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  2:  Virtual  Filestore  Definition 
ISO  8571-2:     1988(E) . 
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Transfer,  Access  and  Management  Part  3:     The  File  Service  Definition, 
ISO  8571-3:  1988(E). 
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Transfer,  Access  and  Management  Part  5:     Protocol  Information 
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Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Service  Definition  for  the  Association  Control  Service  Element,  ISO 
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Information  Processing  Systems  -  Open  Systems  Interconnection  - 
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Information  Processing  System  -  Open  Systems  Interconnection  -  ACSE 
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ACSE  Service,  ISO  8649/DAD2. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
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Service,  ISO  IS  10035:     1989-02-25  (ISO/IEC  JTC1/SC21  N  3456). 


Application  Layer  VTP 


Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Virtual  Terminal  Service  -  Basic  Class,   IS  9040. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Virtual  Terminal  Protocol  -  Basic  Class,  IS  9041. 


Application  Process  --  Office  Document  Interchange  --  ODA 

ISO  8613/1  -  Information  processing  :  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  1: 
Introduction  and  General  Principles 

ISO  8613/2  -  Information  processing  :  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  2:  Document 
Structures 


ISO  8613/4  -  Information  processing  :  Text  and  Office  Systems;  Office 
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Document  Architecture  (ODA)  and  Interchange  Format  Part  4:  Document 
Profile 

ISO  8613/5  -  Information  processing  :  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  5:  Office 
Document  Interchange  Format 

ISO  8613/6  -  Information  processing  :  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  6:  Character 
Content  Architectures 

ISO  8613/7  -  Information  processing  :  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  7:  Raster 
Graphics  Content  Architectures 

ISO  8613/8  -  Information  processing  :  Text  and  Office  Systems;  Office 
Document  Architecture  (ODA)  and  Interchange  Format  Part  8:  Geometric 
Graphics  Content  Architectures 

Application    Process  --  Computer  Graphics  --  CGM/GKS 

Information  Processing  Systems  -  Computer  Graphics  -  Metafile  (CGM) 
for  the  Storage  and  Transfer  of  Picture  Description  Information,  Part 
1;  Functional  Specification,  IS  8632/1 

Information  Processing  Systems  -  Computer  Graphics  -  Metafile  (CGM) 
for  the  Storage  and  Transfer  of  Picture  Description  Information,  Part 
2;  Character  Encoding,  IS  8632/2 

Information  Processing  Systems  -  Computer  Graphics  -  Metafile  (CGM) 
for  the  Storage  and  Transfer  of  Picture  Description  Information,  Part 
3;  Binary  Encoding,  IS  8632/3. 

Information  Processing  Systems  -  Computer  Graphics  -  Metafile  (CGM) 
for  the  Storage  and  Transfer  of  Picture  Description  Information,  Part 
4;  Clear  Text  Encoding,  IS  8632/4, 

Information  Processing  Systems  -  Font  and  Character  Information 
Interchange,   IS  9541. 

Information  Processing  Systems  -  8-Bit  Single  Byte  Coded  Graphic 
Character  Sets,  Part  1;  Latin  Alphabet  Part  1,  IS  8859/1. 

Information  Processing  Systems  -  Computer  Graphics  Functional 
Specification  of  the  Graphical  Kernel  System  (GKS) ,  IS  7942. 

Information  Processing  Systems  -  Computer  Graphics  -  Graphical  Kernel 
System  for  Three  Dimensions  (GKS-3D),  Functional  Description,  DIS 
8805. 
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Information  Processing  Systems  -  Computer  Graphics  -  Programmers 
Hierarchical  Interactive  Graphics  System  (PHIGS) ,  DP  9592. 

Information  Processing  Systems  -  Computer  Graphics  -  Interfacing 
Techniques  for  Dialogues  with  Graphical  Devices  (CGI), ISO  TC  97/SC  21 
N  1179. 

Application  Layer  --  Directory  Services 

The  Directory- -Overview  of  Concepts,  Models,  and  Services  (CCITT 
Recommendation  X.500,  ISO  9594) 

The  Directory- -Information  Framework  (CCITT  Recommendation  X.501,  ISO 
9594) 

The  Directory- -Access  and  System  Services  Definition  (CCITT 
Recommendation  X.511,  ISO  9594) 

The  Directory- -Procedures  For  Distributed  Operation  (CCITT 
Recommendation  X.518,   ISO  9594) 

The  Directory- -Access  and  System  Protocols  Specification  (CCITT 
Recommendation  X.519,  ISO  9594) 

The  Directory- -Selected  Attribute  Types  (CCITT  Recommendation  X.520, 
ISO  9594) 

The  Directory--Selected  Object  Classes  (CCITT  Recommendation  X.521, 
ISO  9594) 

The  Directory- -Authentication  Framework  (CCITT  Recommendation  X.509, 
ISO  9594) 

Remote  Operations-Part  1:  Model,  Notation  and  Service  Definition 
(CCITT  Recommendation  X.219,  ISO  9072  Version  5) 

Remote  Operations -Part  'I:  Protocol  Specification  (CCITT  Recommendation 
X.229,   ISO  9072  Version  5) 

Association  Control -Service  Definition  (CCITT  Recommendation  X217,  ISO 
8649) 

Association  Control-Protocol  Definit  ion  (CCITT  Recommendation  X.217, 
ISO  8650) 

Note:  ISO  9594,  9072  are  preferred  texts  (over  the  CCITT 

counterparts)  and  are  to  be  taken  as  of  Gloucester, 
Nov.  1987. 
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Additional  ISO  References 

ISO  8859-1  -  Information  Processing  -  8-bit  Single-byte  Coded  Graphic 
Character  Sets  -  Part  1:  Latin  Alphabet  No.  1 

ISO  8859-2  -  Information  Processing  -  8-bit  Single-byte  Coded  Graphic 
Character  Sets  -  Part  2:  Latin  Alphabet  No.  2 

DIS  8859-3  -  Information  Processing  -  8-bit  Single-Byte  Coded  Graphic 
Character  Sets  -  Part  3:  Latin  Alphabet  No.  3 

ISO  6937-1  -  Information  Processing  -  Coded  Character  Sets  for  Text 
Communication  -  Part  1 :  General  Introduction 


ISO  6937-2  -  Information  Processing  -  Coded  Character  Sets  for  Text 
Communication  -  Part  2:  Latin  Alphabetic  and  Non-Alphabetic  Graphic 
Characters 


ISO  2022  -  Information  Processing  -  ISO  7-Bit  and  8-Bit  Coded 
Character    Sets  -  Code  Extension  Techniques 

7-Bit  Coded  Character  Set  for  Information  Processing  Interchange,  ISO 
646. 


ISO  6429:     1988  Information  Processing  -  ISO  7-Bit  and  8-Bit  Coded 
Character  Sets  -  Additional  Control  Functions  for  Character- Imaging 
Devices . 


ISO/IEC  ISP  AFTnn- Information  Technology  Processing -Systems  - 
International  Standardized  Profiles  AFTnn  -  File  Transfer,  Access  and 
Management . 


Part  1  Specification  of  ACSE,  Presentation  and  Session 
Protocols  for  the  use  by  FTAM  PDISP  t989-06-01 . 
1990-01-10. 

Part  2        Definition  of  Document  Types,  Constraint  Sets  and 
Syntaxes  PDISP  1989-06-017  1990-01-10. 

Part  2        Definition  of  Document  Types,  Constraint  Sets  and 

Syntaxes,  Addendum  1:  Additional  Defintions  Working 
Draft  1989-08-157  1990-01-10. 


Part  3        AFTll-Simple  File  Transfer  Service  (Unstructured)  PDISP 
1989-06-017  1990-01-10. 


Part  4       AFTl 2 -Positional  File  Transfer  Service  (Flat)  Working 
Draft  1989-08-157  1990-01-10. 
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Part  5        AFT22-Positlonal  File  Access  Service  (Flat)  Working 
Draft  t989-G8-l:ST  1990-01-10. 

Part  6        AFT3-File  Management  Service  Working  Draft  t9&9-G8-t5T 
1990-01-10. 

ISO  documents  may  be  obtained  from: 

Frances  E.  Schrotter 
ANSI 

ISO  TC  97/SC  6  Secretariat 
1430  Broadway 
New  York.  NY.  10018 

21 . 3  Additional  References 

INTAP-S007-03  -  Multi-media  (ODA/ODIF)  Functional  Standard  Detail 
Description  (AE.llln-J),  Small  Function  Set  Profiles  of  Document 
Interchange  Format  with  Layout  Information 

INTAP-S007-04  -  Multi-media  (ODA/ODIF)  Functional  Standard  Detail 
Description  (AE.112n-J),  Medium  Function  Set  Profiles  of  Document 
Interchange  Format  with  Layout  Information 

21.4  IEEE 
Physical  Layer 

IEEE  Standard  for  Local  Area  Networks:     Carrier  Sense  Multiple  Access 
with  Collision  Detection  (CSMA/CD)  and  Physical  Layer  Specification, 
ANSI/IEEE  Standard  802.3  1985,  Institute  of  Electrical  and  Electronics 
Engineers,  345  East  47th  St.,  New  York,  NY.  10017,  1985. 

IEEE  Standard  for  Local  Area  Networks:  Supplements  to  Carrier  Sense 
Multiple  Access  with  Collision  Detection  (CSMA/CD)  Access  Method  and 
Physical  Layer  Specification  ANSI. IEEE  Standard  802.3a,  b,  c,  e  -1988 

Supplement  a,  MAU  and  Baseband  Medium  Specification,  lyp^  10BASE2 
(Section  10) 

Supplement  a.  Broadband  MAU  6e  Medium  Specification,  Type  10BROAD36 
(Section  11) 

Supplement  c.  Repeater  Set  and  Repeater  Unit  Specification  for  Use 
with  10BASE5  and  10  BASE2  Networks 

Supplement  e,  Physical  Signaling,  Medium  Attachment,  and  Baseband 
Medium  Specification,  Type  10BASE5 
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IEEE  Standard  for  Local  Area  Networks:     Token-Passing  Bus  Access 
Method  and  Physical  Layer  Specification,  ANSI/IEEE  Standard  ,  802.4 
Draft  1987,  Institute  of  Electrical  and  Electronics  Engineers,  345 
East  47th  St.,  New  York,  NY.   10017,  1985. 

IEEE  Standard  for  Local  Area  Networks:     Token-Ring  Access  Method, 
ANSI/IEEE  Standard  802.5-  1986,   Institute  of  Electrical  and 
Electronics  Engineers,  345  East  47th  St.,  New  York,  NY.   10017,  1985. 

Data  Link  Layer 

IEEE  Standard  for  Local  Area  Networks:  Logical  Link  Control, 
ANSI/IEEE  Standard  802.2  -  1987,  Institute  of  Electrical  and 
Electronics  Engineers,  345  East  47th  St.,  New  York,  NY.  10017,  1985. 


21 .5  NBS 


Implementation  Agreements  for  Open  Systems  Interconnection  Protocols: 
NBS  Workshop  for  Implementors  of  Open  Systems  Interconnection, 
National  Bureau  of  Standards,  NBSIR  86-3385-6,  Robert  Rosenthal, 
Editor,  Revised  July  1987. 

U.  S.  Government  Open  Systems  Interconnection  Profile  (GOSIP) , 
National  Bureau  of  Standards,   Institute  for  Computer  Sciences  and 
Technology,  1987. 

NBS  documents  may  be  obtained  from: 

NTIS 

U.S.  Department  of  Commerce 
5285  Port  Royal  Road 
Springfield,  VA.  22161. 


21 .6  MAP 

Manufacturing  Automation  Protocol,  General  Motors 
Corporation, Manufacturing  Engineering  and  Development,  Advanced 
Product  and  Manufacturing  Engineering  Staff  (APMES) ,  APMES  A/MD-39,  GM 
Technical  Center,  Warren,  MI.  48090-9040. 


21.7  TOP 


Technical  and  Office  Protocols  Specification  Version  3.0,  MAP/TOP 
Users  Group,  Attention  TOP  3.0  Document.     One  SME  Drive,   P.O.  Box  930, 
Dearborn  Mi.  48121. 
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21 .8  CEN/CENELEC 

ENV-4]:2G4h--i988fE)  ENV  41204  (revised):     1990(E)  FTAM  Simple  File 
Transfer  (Unstructured),  June  Jan.  1990  (-proposed -revision -June -t989)  . 

prENV  41205  FTAM  File  Management,  March  Nov.  1989. 

prENV  41206  FTAM  Positional  File  Transfer  (Flat),  June-t989  Jan.  1990. 
prENV  41207  FTAM  Postional  File  Access  (Flat),  June-1:989  Jan.  1990. 
ENV  41201  "Private  Message  Handling  Systems" 
ENV  41202  "Public  Message  Handling  Systems" 


21.9  SPAG 

Guide  to  the  Use  of  Standards,  Revision  4.0  1989. 


21 . 10  ANSI 
Physical  Layer 

Fiber  Distributed  Data  Interface  (FDDI)  -  Token  Ring  Media  Access 
Control  (MAC);  ANS  X3. 139-1987  (for  Working  Agreements  only). 

Fiber  Distributed  Data  Interface  (FDDI)  -  Token  Ring  Physical  Layer 
Protocol  (PHY);  ANS  X3. 148-1988  (for  Working  Agreements  only). 

Fiber  Distributed  Data  Interface  (FDDI)  -  Physical  Layer  Medium 
Dependent  (PMD) ;  ANS  X3. 166-1989  (for  Working  Agreements  only). 

Carrier- to-Customer  Installation  -  DSl  Metallic  Interface,  ANS  Tl.403 
-  1989. 

Integrated  Services  Digital  Network  -  Basic  Access  Interface  for  Use 
on  Metallic  Loops  for  Application  on  the  Network  Side  of  the  NT-Layer 
1  Specification,  ANS  T1.601  -  1988. 

Integrated  Services  Digital  Network  -  Basic  Access  Interface  at  S  and 
T  Reference  Points  -  Layer  1  Specification,  ANS  T1.605  -  1988. 

Data  Link  Layer 

Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  - 
Data-Link  Layer  Signaling  Specification  for  Application  at  the  User- 
Network  Interface,  ANS  T1.602  -  1989. 
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functionality.  All  changes  apply  to  the  previous  version  and  edition. 
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Technical  errata  are  changes  from  implementor  experience  which  materially 
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not  change  semantics.  Alignment  changes  are  material  changes  made  in  the 
interest  of  international  harmonization  and  evolving  base  standards. 

In  general,  technical  errata  are  more  "severe"  than  editorial  errata,  and 
alignment    errata    are    more    "severe"     than    technical    errata.        If  a 
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particular  replacement  has  a  combination  of  errata,  the  most  "severe" 
errata  will  be  checked  in  the  replacement  page  table.  Readers  should 
keep  iri  mind  that  these  errata  may  be  further  categorized  in  future 
editions . 
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